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

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

Definición de compatibilidad de Android 4.1

Definición de compatibilidad de Android 4.1
Revisión 3
Última actualización: 24 de junio de 2013
Derechos de autor © 2012, Google Inc. Todos los derechos reservados.
compatibility@android.com
Índice
1. Introducción
2. Recursos
3. Software
3.1. Compatibilidad con APIs administradas
3 .2. Compatibilidad de API flexible
3.2.1. Permisos
3.2.2. Parámetro de compilación
3 .2.3. Compatibilidad con intents
3.2.3.1. Intents de aplicación principales
3.2.3.2. Anulación de intents
3.2.3.3. Espacios de nombres de intents
3.2.3.4. Intents de transmisión
3.3. Compatibilidad con APIs nativas
3.3.1 Interfazes binarias de aplicación
3.4. Compatibilidad web
3.4.1. Compatibilidad con WebView
3.4.2. Compatibilidad del navegador
3.5. Compatibilidad comportamental de la API
3.6. Espacios de nombres de la API
3.7. Compatibilidad con máquinas virtuales
3.8. Compatibilidad con la interfaz de usuario
3.8.1. Widgets
3.8.2. Notificaciones
3.8.3. Buscar
3.8.4. Toasts
3.8.5. Temas
3.8.6. Papel de Wal
en vivo 3.8.7. Pantalla de aplicación reciente
3.8.8. Input Management Settings
3.8.9. Control remoto de la pantalla de bloqueo
3.9 Dministración de dispositivos
3.10 Accesibilidad
3.11 Texto a voz
4. Compatibilidad de empaquetado de aplicaciones
5. Compatibilidad multimedia
5.1. Códecs multimedia
5.2. Codificación de video
5.3. Grabación de audio
5.4. Latencia de audio
5.5. Protocolos de red
6. Compatibilidad con herramientas para desarrolladores
7.Compatibilidad con el hardware
7.1. Pantalla y gráficos
7.1.1. Configuración de la pantalla
7.1.2. Métricas de Display
7.1.3. Orientación de la pantalla
7.1.4. Aceleración de gráficos 2D y 3D
7.1.5. Modo de compatibilidad de la aplicación heredada
7.1.6. Tipos de pantallas
7.1.7. Tecnología de la pantalla
7.2. EnDispositivos de entrada
7.2.1. Teclado
7.2.2. Navigation sin tacto
7.2.3. Teclas de navegación
7.2.4. Entrada táctil
7.2.5. Entrada táctil falsificada
7.2.6. Micrófono
7.3. Sensores
7.3.1. Acelerómetro

7.3.1. Acelerómetro
7.3.2. Magnetómetro
7.3.3. GPS
7.3.4. Giroscopio
7.3.5. Barómetro
7.3.6. Termómetro
7.3.7. Fotometro
7.3.8. Sensor de proximidad
7.4. Conectividad de datos
7.4.1. Telefonía
7.4.2. IEEE 802.11 (Wi-Fi)
7.4.2.1. Wi-Fi Direct
7.4.3. Bluetooth
7.4.4. Comunicación de campo cercano
7.4.5. Capacidad de red mínima
7.5. Cámaras
7.5.1. Cámara posterior:
7.5.2. Cámara frontal
7.5.3. Comportamiento de la API de Camera
7.5.4. Orientación de la cámara
7.6. Memoria y almacenamiento
7.6.1. Memoria y almacenamiento mínimos
7.6.2. Almacenamiento compartido de la aplicación
7.7. USB
8. Performance Compatibility
9. Compatibilidad de modelos de seguridad
9.1. Permisos
9.2. UID y aislamiento del proceso
9.3. Permisos del sistema de archivos
9.4. Entornos de ejecución alternativos
10. Pruebas de compatibilidad de software
10.1. Conjunto de pruebas de compatibilidad
10.2. Verificador del CTS
10.3. Aplicaciones de referencia
11. Software actualizable
12. Contact Us
Apéndice A: Procedimiento de prueba de Bluetooth

1. Introducción
En este documento, se enumeran los requisitos que deben cumplirse para que los dispositivos
sean compatibles con Android 4.1.
El uso de “debes”, “no debes”, “obligatorio”, “debe ", “debe  no”, “deberías”, “no deberías”,
“recomendado”, “puedes” y “opcional” es según el estándar de IETF definido en RFC2119
[Recursos, 1].
Según se usa en este documento, un "implementador de dispositivos" o "implementador" es una persona o
organización que desarrolla una solución de hardware/software que ejecuta Android 4.1. Una "implementación
de dispositivos" o "implementación" es la solución de hardware y software que se desarrolla.
Para que se consideren compatibles con Android 4.1, las implementaciones del dispositivo DEBEN cumplir
los requisitos que se presentan en esta Definición de Compatibilidad, incluidos los documentos
incorporados a través de referencia.
Cuando esta definición o las pruebas de software descritas en el Artículo 10 no se mencionan, son
ambiguas o incompletas, es responsabilidad del desarrollador de dispositivos garantizar la
compatibilidad con implementaciones existentes.
Por este motivo, el Proyecto de código abierto de Android [Recursos, 3] es la implementación de referencia
y preferida de Android. Se recomendaa los implementadores de dispositivos que basen sus implementaciones en la mayor medida posible en el código fuente"upstream" disponible en el Proyecto de Código Abierto de Android.

Si bien algunos
componentes pueden ser hipotéticos y reemplazarse por implementaciones alternativas, esta
práctica no se recomienda en absoluto, ya que aprobar las pruebas de software se  volverá
más difícil. Es responsabilidad del implementador garantizar la total  compatibilidad conductual con la implementación estándar de Android, incluida y más allá del
conjunto de pruebas de compatibilidad.
Por último, ten en cuenta que este documento prohíbe de forma explícita ciertas sustituciones y
modificaciones de componentes.
2. Recursos
1.  Niveles de requisitos de la RFC2119 del IETF: http://www.ietf.org/rfc/rfc2119.txt
2.  Descripción general del Programa de Compatibilidad de Android:
http://source.android.com/compatibility/index.html
3.  Proyecto de código abierto de Android: http://source.android.com/
4.  Definiciones y documentación de la API:
http://developer.android.com/reference/packages.html
5.  Referencia de permisos de Android:
http://developer.android.com/reference/android/Manifest.permission.html
6.  Referencia de android.os.Build:
http://developer.android.com/reference/android/os/Build.html
7.  Android 4.1 al owed version strings:
http://source.android.com/compatibility/4.1/versions.html
8.  Renderscript:
http://developer.android.com/guide/topics/graphics/renderscript.html
9.  Aceleración por hardware:
http://developer.android.com/guide/topics/graphics/hardware-accel.html
10.  Clase android.webkit.WebView:
http://developer.android.com/reference/android/webkit/WebView.html
11.  HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12.  Funciones sin conexión de HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13.  Etiqueta de video HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14.  API de geolocalización de HTML5/W3C: http://www.w3.org/TR/geolocation-API/
15.  API de base de datos web API de HTML5/W3C: http://www.w3.org/TR/webdatabase/
16.API de IndexedDB de HTML5/W3C: http://www.w3.org/TR/IndexedDB/
17.Especificación de la máquina virtual Dalvik: disponible en el código fuente de Android, en
dalvik/docs
18.  AppWidgets:
http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19.  Notificaciones:
http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20.  Recursos de la aplicación: http://code.google.com/android/reference/available-
resources.html
21.  Guía de estilo de íconos de la barra de estado:
http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22.  Administrador de búsqueda:
http://developer.android.com/reference/android/app/SearchManager.html
23.  Toasts: http://developer.android.com/reference/android/widget/Toast.html
24.  Temas: http://developer.android.com/guide/topics/ui/themes.html

25.  Clase R.style: http://developer.android.com/reference/android/R.style.html
26.  Fondos de pantalla en vivo: http://developer.android.com/resources/articles/live-
wal papers.html
27.  Administración de dispositivos Android:
http://developer.android.com/guide/topics/admin/device-admin.html
28.  Clase android.app.admin.DevicePolicyManager:
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29.  APIs de Accessibility Service de Android:
http://developer.android.com/reference/android/accessibilityservice/package-
summary.html
30.  APIs de accesibilidad de Android:
http://developer.android.com/reference/android/view/accessibility/package-
summary.html
31.  Proyecto Eyes Free: http://code.google.com/p/eyes-free
32.  APIs de Text-To-Speech:
http://developer.android.com/reference/android/speech/tts/package-
summary.html
33.  Documentación de herramientas de referencia (para adb, aapt, ddms):
http://developer.android.com/guide/developing/tools/index.html
34.  Descripción del archivo apk de Android:
http://developer.android.com/guide/topics/fundamentals.html
35.  Archivos de manifiesto: http://developer.android.com/guide/topics/manifest/manifest-
intro.html
36.  Herramienta de prueba de Monkey:
https://developer.android.com/studio/test/other-testing-tools/monkey
37.  Lista de funciones de hardware y de la clase android.content.pm.PackageManager
de Android:
http://developer.android.com/reference/android/content/pm/PackageManager.html
38.  Compatibilidad con varias pantallas:
http://developer.android.com/guide/practices/screens_support.html
39.  android.util.DisplayMetrics:
http://developer.android.com/reference/android/util/DisplayMetrics.html
40.  android.content.res.Configuration:
http://developer.android.com/reference/android/content/res/Configuration.html
41.  android.hardware.SensorEvent:
http://developer.android.com/reference/android/hardware/SensorEvent.html
42.  API de Bluetooth:
http://developer.android.com/reference/android/bluetooth/package-summary.html
43.  Protocolo de empuje NDEF: http://source.android.com/compatibility/ndef-push-
protocol.pdf
44.  MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45.  MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46.  MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47.  MIFARE MF0ICU2:
http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48.  MIFARE AN130511:
http://www.nxp.com/documents/application_note/AN130511.pdf
49.  MIFARE AN130411:
http://www.nxp.com/documents/application_note/AN130411.pdf
50.  API de orientación de la cámara:
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51.  android.hardware.Camera:
http://developer.android.com/reference/android/hardware/Camera.html
52.  Accesorios abiertos de Android:
http://developer.android.com/guide/topics/usb/accessory.html
53.  API del host USB: http://developer.android.com/guide/topics/usb/host.html
54.  Referencia de seguridad y permisos de Android:
http://developer.android.com/guide/topics/security/security.html
55.  Apps para Android: http://code.google.com/p/apps-for-android
56.  Clase android.app.DownloadManager:
http://developer.android.com/reference/android/app/DownloadManager.html
57.  Transferencia de archivos de Android: http://www.android.com/filetransfer
58.  Formatos multimedia de Android: http://developer.android.com/guide/appendix/media-
formats.html
59.  Protocolo de borrador para HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-
live-streaming-03
60.  NFC Connection Handover: http://www.nfc-
forum.org/specs/spec_list/#conn_handover
61.  Vinculación segura simple por Bluetooth con NFC: http://www.nfc-
forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62.  API de multicast de Wi-Fi:
http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

63.  Asistente de acciones:
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64.  Especificaciones de carga USB:
http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65.  Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66.  Audio USB de Android:
http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67.  Configuración de Compartir NFC de Android:
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68.  Wi-Fi Direct (Wi-Fi P2P):
http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69.  Cliente de control remoto de media:
http://developer.android.com/reference/android/media/RemoteControlClient.html
70.  API de Motion Event:
http://developer.android.com/reference/android/view/MotionEvent.html
71.  Configuración de entrada táctil: http://source.android.com/tech/input/touch-
devices.html
Muchos de estos recursos se obtienen directa o indirectamente del SDK de Android 4.1,
y serán  funcionales y idénticos a la información de la documentación de ese SDK. En casos de discrepancias entre esta Definición de Compatibilidad o el Conjunto de Pruebas de Compatibilidad y
la documentación del SDK, la documentación del SDK se considera autorizada.
Cualquier
detalle técnico proporcionado en las referencias incluidas anteriormente se considera por
inclusión como parte de esta Definición de Compatibilidad.
3. Software
3.1. Compatibilidad de API administrada
El entorno de ejecución administrado (basado en Dalvik) es el vehículo principal para las aplicaciones
de Android. La interfaz de programación de aplicaciones (API) de Android es el conjunto de interfaces de la plataforma de
Android expuestas a las aplicaciones que se ejecutan en el entorno de VM
administrado. Las implementaciones del dispositivo DEBEN proporcionar implementaciones completas,
incluidos todos los comportamientos documentados, de cualquier API documentada expuesta por el SDK de Android
4.1 [Recursos, 4].
Las implementaciones de dispositivos NO DEBEN omitir ninguna API administrada, alterar las interfaces o
firmas, desviarse del comportamiento documentado, ni incluir no-ops, excepto cuando
se especifique en esta Definición de Compatibilidad.
Esta definición de compatibilidad permite que las implementaciones de dispositivos omitan algunas APIs de hardware para las que Android
incluye APIs. En estos casos, las APIs DEBEN
  estar presentes y comportarse de una manera razonable. Consulta la Sección 7 para conocer los
requisitos específicos de esta situación.
3.2. Compatibilidad de API "soft"
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 la forma de elementos como Intents, permisos y
aspectos similares de las aplicaciones de 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, 5]. Ten en cuenta que en el Artículo 10
se enumeran los 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
[Resources, 6] que tienen como objetivo describir el dispositivo actual. Para proporcionar valores
significativos y coherentes en las implementaciones de dispositivos, la siguiente tabla incluye
restricciones adicionales sobre los formatos de estos valores a los que las implementaciones de dispositivos DEBEN
conformarse.
Parámetro
Comentarios
Es la versión del sistema Android que se está ejecutando, en formato legible. Este campo DEBE tener un
android.os.Build.VERSION.RELEASE
de los valores de cadena definidos en [Resources, 7].
La versión del sistema Android que se está ejecutando actualmente, en un formato al que pueda acceder el código de aplicación de terceros.
android.os.Build.VERSION.SDK
Para Android 4.1, este campo DEBE tener el valor entero 16.

Es la versión del sistema Android que se está ejecutando actualmente, en un formato al que puede acceder el código de aplicación de terceros.
android.os.Build.VERSION.SDK_INT
En Android 4.1, este campo DEBE tener el valor entero 16.
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 de
android.os.Build.VERSION.INCREMENTAL
. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de 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 la cadena vacía ("").
Es un valor que elige el implementador del dispositivo para identificar el hardware interno específico que usa el dispositivo, en
formato legible por humanos. Un posible uso de este campo es indicar la revisión específica de la placa que alimenta
android.os.Build.BOARD
el dispositivo. El valor de este campo DEBE ser codificable como ASCII de 7 bits y coincidir con la expresión regular
"^[a-zA-Z0-9.,_-]+$".
Es un valor que elige el implementador del dispositivo para identificar el nombre de la empresa, organización, persona, etc.
que produjo el dispositivo, en formato legible por humanos. Un posible uso de este campo es indicar el OEM
android.os.Build.BRAND
o el operador que vendió el dispositivo. El valor de este campo DEBE ser codificable como ASCII de 7 bits y coincidir con la
expresión regular "^[a-zA-Z0-9.,_-]+$".
Es el nombre del conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo.Consulta  Sección 3.3: Compatibilidad con la API
android.os.Build.CPU_ABI
.
Es el nombre del segundo conjunto de instrucciones (tipo de CPU + convención de ABI) del código nativo. Consulta  el artículo 3.3: Compatibilidad de API con
android.os.Build.CPU_ABI2
.
Un valor que elige el implementador del dispositivo para identificar la configuración o revisión específica del cuerpo
android.os.Build.DEVICE
(a veces cal ificado como "diseño industrial") del dispositivo. El valor de este campo DEBE ser codificable como
ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9.,_-]+$".
Es una cadena que identifica de forma única esta compilación. DEBEN ser razonablemente legibles por humanos. DEBEN cumplir con esta
plantilla:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Por ejemplo:
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/JRN53/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, SE DEBEN reemplazar en la huella digital de compilación por otro carácter, como el carácter
guión bajo ("_"). El valor de este campo DEBE ser codificable como ASCII de 7 bits.
Es el nombre del hardware (de la línea de comandos del kernel o /proc). DEBE ser razonablemente legible por
android.os.Build.HARDWARE
humanos. El valor de este campo DEBE ser codificable como ASCII de 7 bits y coincidir con la expresión regular "^[a-
z-A-Z0-9.,_-]+$".
Una cadena que identifica de forma única el host en el que se compiló la compilación, en formato legible por humanos. No hay requisitos de
android.os.Build.HOST
sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
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 suficientemente
android.os.Build.ID
significativo para que los usuarios finales puedan distinguir entre compilaciones de software. El valor de este campo DEBE ser codificable
como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9.,_-]+$".
Es el nombre comercial del fabricante del equipo original (OEM) del producto. No hay requisitos en
android.os.Build.MANUFACTURER
el formato específico de este campo, excepto que NO DEBE ser nulo  ni la cadena vacía ("").
Un valor que elige el implementador del dispositivo que contiene el nombre del dispositivo tal como lo conoce el usuario final. Este
android.os.Build.MODEL
DEBE ser el mismo nombre con el que se comercializa y vende el dispositivo a los usuarios finales. No hay
requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo ni la cadena vacía ("").
Es un valor que elige el implementador del dispositivo que contiene el nombre de desarrollo o el nombre de código del producto
android.os.Build.PRODUCT
(SKU). DEBEN ser legibles por humanos, pero no necesariamente están destinados a la visualización por parte de los usuarios finales. El valor de este
campo DEBE ser codificable como ASCII de 7 bits y coincidir con la expresión regular "^[a-zA-Z0-9.,_-]+$".
Un número de serie de hardware, si está disponible. El valor de este campo DEBE ser codificable como ASCI de 7 bits y coincidir con
android.os.Build.SERIAL
la expresión regular "^([a-zA-Z0-9]{0,20})$".
Es una lista de etiquetas separadas por comas que elige el implementador del dispositivo y que distingue más la compilación. Por ejemplo, "unsigned,debug" para
android.os.Build.TAGS
. El valor de este campo DEBE ser codificable como ASCII de 7 bits y coincidir con la expresión
regular "^[a-zA-Z0-9.,_-]+$".
android.os.Build.TIME
Un valor que representa la marca de tiempo de cuándo ocurrió la compilación.
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
DEBERIA tener uno de los valores correspondientes a las tres configuraciones típicas del entorno de ejecución de Android: "user",
android.os.Build.TYPE
"userdebug", o "eng". El valor de este campo DEBE ser codificable como ASCII de 7 bits y coincidir con la expresión
regular "^[a-zA-Z0-9.,_-]+$".
Un nombre o ID de usuario del usuario (o usuario automatizado) que generó la compilación. No hay requisitos en
android.os.Build.USER
el formato específico de este campo, excepto que NO DEBE ser nulo  ni la cadena vacía ("").
3.2.3. Compatibilidad con intents
Las implementaciones del dispositivo DEBEN respetar el sistema de intents de vinculación flexible de Android, como

se describe en las secciones que siguen. Cuando se dice que se "respeta", se quiere decir que el implementador del dispositivo
DEBE proporcionar una actividad o un servicio de Android que especifique un filtro de intent que coincida y
se vincule a y ejecute el comportamiento correcto para cada patrón de intent especificado.
3.2.3.1. Intentos de aplicación principales
El proyecto upstream de Android define una serie de aplicaciones principales, como contactos,
calendario, galería de fotos, reproductor de música, etcétera. Los implementadores de dispositivos PUEDEN reemplazar
estas aplicaciones por versiones alternativas.
Sin embargo, cualquier versión alternativa DEBE respetar los mismos patrones de intent que proporciona
el proyecto upstream. Por ejemplo, si un dispositivo contiene un reproductor de música alternativo,
debe seguir respetando el patrón de Intent que emiten las aplicaciones de terceros para elegir una canción.
Las siguientes aplicaciones se consideran aplicaciones principales del sistema Android:
Reloj de escritorio
Navegador
Calendario
Contactos
Gal ería
GlobalSearch
Selector
Música
Configuración
Las aplicaciones principales del sistema Android incluyen varios componentes de actividad o servicio
que se consideran "públicos". Es decir, el atributo "android:exported" puede estar ausente, o
puede tener el valor "true".
Para cada Actividad o Servicio definido en una de las apps del sistema principal de Android que no esté
marcada como no pública a través de un atributo android:exported con el valor "false", las implementaciones
del dispositivo DEBEN incluir un componente del mismo tipo que implemente los
mismos patrones de filtro de intent que la app del sistema principal de Android.
En otras palabras, una implementación del dispositivo PUEDE reemplazar las apps del sistema principal de Android.
Sin embargo, si lo hace, la implementación del dispositivo DEBE admitir todos los patrones de intent definidos
por cada app del sistema principal de Android que se reemplaza.
3.2.3.2. Anulaciones de intent
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.2. La
implementación de código abierto de Android upstream lo permite de forma predeterminada. Los
implementadores de dispositivos NO DEBEN asignar privilegios especiales al uso de
estos patrones de Intent, ni evitar que las aplicaciones de terceros se vinculen a estos patrones y asuman el
control de ellos. Esta prohibición específica mente incluye pero no se limita a
inhabilitar la interfaz de usuario "Chooser" que le permite al usuario seleccionar entre varias
aplicaciones que también 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 intent 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
para los intents.
3.2.3.3. Espacios de nombres de intents
Las implementaciones de dispositivos NO DEBEN incluir ningún componente de Android que respalde ningún patrón de intent o intent de publicación nuevo con un ACTION, CATEGORY o cualquier 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 respalde ningún patrón nuevo de intent o intent de publicación
con una ACTION, CATEGORY o cualquier otra cadena clave en un espacio de paquete que pertenece a
otra organización. Los implementadores de dispositivos NO DEBEN alterar ni extender ningún de los patrones de Intent
que usan las apps principales que se mencionan en el artículo 3.2.3.1. Las implementaciones de dispositivos PUEDEN
incluir patrones de intents que usen espacios de nombres de forma clara y obvia asociados con su
propia organización.
Esta prohibición es análoga a la especificada para las clases del lenguaje Java en el artículo
3.6.
3.2.3.4. Intents de transmisión
Las aplicaciones de terceros dependen de la plataforma para transmitir ciertos intents que les notifiquen

los cambios en el entorno de hardware o software. 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 publicación se describen en la documentación del SDK.
3.3. Compatibilidad con APIs nativas
3.3.1 Interfaz binaria de aplicación
El código administrado que se ejecuta en Dalvik puede convertirse en código nativo proporcionado en el archivo
.apk de la aplicación como un archivo .so ELF compilado para la arquitectura de hardware del dispositivo adecuada.
Dado que el código nativo depende en gran medida de la tecnología del procesador subyacente, Android
define una serie de interfaz binaria de aplicación (ABI) en el NDK de Android, en el archivo
docs/CPU-ARCH-ABIS.html. Si una implementación de dispositivo es compatible con una o más ABI definidas por
, DEBE implementar la compatibilidad con el NDK de Android, como se describirá a continuación.
Si una implementación de dispositivo incluye compatibilidad con una ABI de Android, debe hacer lo siguiente:
DEBERÁ incluir compatibilidad con código que se ejecute en el entorno administrado para convertirlo en
código nativo, mediante la semántica estándar de la interfaz nativa de Java (JNI).
DEBERÁ ser compatible con la fuente (es decir, compatible con el encabezado) y con el código binario (para
la ABI) con cada biblioteca obligatoria de la siguiente lista
DEBERÁ informar con precisión la interfaz binaria de aplicación (ABI) nativa compatible
con el dispositivo, a través de la API android.os.Build.CPU_ABI
DEBERÁ informar solo aquellas ABIs documentadas en la versión más reciente del NDK de Android, en el archivo docs/CPU-ARCH-ABIS.txt
DEBEN 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 incluyan código nativo:
libc (biblioteca C)
libm (biblioteca matemática)
Compatibilidad mínima con la interfaz de JNI de C++
liblog (registro de Android)
libz (compresión Zlib)
libdl (vinculador dinámico)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libEGL.so (administración de superficies OpenGL nativa)
libjnigraphics.so
libOpenSLES.so (compatibilidad con audio OpenSL ES 1.0.1)
libOpenMAXAL.so (compatibilidad con OpenMAX AL 1.0.1)
libandroid.so (compatibilidad con actividades nativas de Android)
Compatibilidad con OpenGL, como se describe a continuación
Ten en cuenta que las versiones futuras del NDK de Android pueden incluir compatibilidad con ABIs adicionales.

Si una implementación de dispositivo no es compatible con una ABI predefinida existente,
NO DEBE informar compatibilidad con ningún ABI en absoluto .
La compatibilidad con el código nativo es un desafío. Por este motivo, se debe repetir que a los implementadores de
dispositivos se les recomienda MUY FELIZMENTE que usen las implementaciones
upstream de las bibliotecas mencionadas anteriormente para ayudar a garantizar la compatibilidad.
3.4. Compatibilidad web
3.4.1. Compatibilidad con WebView
La implementación de código abierto de Android usa el motor de renderización WebKit para
implementar el android.webkit.WebView. Dado que no es posible 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 WebKit en la implementación de WebView. Específicamente:
Las implementaciones de android.webkit.WebView de las implementaciones de dispositivos DEBEN estar
basadas en la compilación 534.30 de WebKit del árbol de código abierto de Android upstream
para Android 4.1. Esta compilación incluye un conjunto específico de correciones de funcionamiento y seguridad
para WebView. Los implementadores de dispositivos PUEDEN incluir personalizaciones en la implementación de
WebKit. Sin embargo, cualquier personalización de este tipo NO DEBE alterar el
comportamiento de WebView, incluido el comportamiento de renderización.
La cadena del usuario-agente que informa WebView DEBE estar en este formato:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)
Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.1
Mobile Safari/534.30
El valor de la cadena $(VERSION) DEBE ser el mismo que el valor para

El valor de la cadena $(VERSION) DEBE ser el mismo que el valor para
android.os.Build.VERSION.RELEASE
El valor de la cadena $(LOCALE) DEBE seguir las convenciones ISO para
código de país y idioma, y DEBE referirse a la configuración actual
regional del dispositivo
El valor de la cadena $(MODEL) DEBE ser el mismo que el valor para
android.os.Build.MODEL
El valor de la cadena $(BUILD) DEBE ser el mismo que el valor para
android.os.Build.ID
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 HTML5
[Recursos, 11]. De forma mínima, las implementaciones de dispositivos DEBEN ser compatibles con cada una de
estas APIs asociadas con HTML5 en WebView:
operación en caché o sin conexión de la aplicación [Recursos, 12]
la etiqueta <video> [Recursos, 13]
la geolocalización [Resources, 14]
Además, las implementaciones de dispositivos DEBEN ser compatibles con la API de webstorage de HTML5/W3C
[Recursos, 15] y DEBEN ser compatibles con la API de IndexedDB de HTML5/W3C [Recursos,
16]. Ten en cuenta que, a medida que los organismos de estándares de desarrollo web están transitando para favorecer a
IndexedDB sobre webstorage, se espera que IndexedDB se convierta en un componente obligatorio
en una versión futura de Android.
Las APIs de HTML5, al igual que las de JavaScript, DEBEN estar inhabilitadas de forma predeterminada en un WebView,
a menos que el desarrollador las habilite de forma explícita a través de las APIs habituales de Android.
3.4.2. Compatibilidad del navegador
Las 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
distinta de WebKit. Sin embargo, incluso si se usa una aplicación de navegador alternativa, el componente
android.webkit.WebView proporcionado a aplicaciones de terceros DEBE estar
basado en WebKit, como se describe en el artículo 3.4.1.
Las implementaciones PUEDEN enviar una cadena de usuario-agente personalizada en la aplicación standalone del navegador
.
La aplicación de navegador independiente (ya sea basada en la aplicación de navegador
WebKit upstream o en un reemplazo de terceros) DEBERIA incluir compatibilidad con la mayor cantidad posible de
HTML5 [Recursos, 11].De forma mínima, las implementaciones de dispositivos DEBEN admitir
cada una de estas APIs asociadas con HTML5:
operación en caché/sin conexión de la aplicación [Recursos, 12]
la etiqueta <video> [Recursos, 13]
la geolocalización [Recursos, 14]
Además, las implementaciones de dispositivos DEBEN admitir la API de HTML5/W3C webstorage
[Recursos, 15], y DEBEN admitir la API de HTML5/W3C IndexedDB [Recursos,
16]. Ten en cuenta que, a medida que los organismos de estándares de desarrollo web realizan la transición para favorecer
IndexedDB sobre webstorage, se espera que IndexedDB se convierta en un
componente obligatorio en una versión futura de Android.
3.5. Compatibilidad conductual 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, 3]. Algunas áreas específicas de compatibilidad son las siguientes:
Los dispositivos NO DEBEN cambiar el comportamiento ni la semántica de un Intent estándar
Losdispositivos 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
porciones significativas de la plataforma para la compatibilidad conductual, pero no todas . Es la
responsabilidad del implementador garantizar la compatibilidad conductual 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 espacios de nombres de paquete y clase definidas por el lenguaje de programación

Java. Para garantizar la compatibilidad con aplicaciones de terceros, los implementadores
de dispositivos NO DEBEN hacer ninguna modificación prohibida (consulta más abajo) a estos
espacios de nombres de paquetes:
java.*
javax.*
sun.*
android.*
com.android.*
Las modificaciones prohibidas incluyen lo siguiente:
Las implementaciones de dispositivos NO DEBEN modificar las APIs expuestas públicamente en la plataforma
Android cambiando cualquier firma de método o clase, 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 y 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 upstream. 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 hacer modificaciones solo internas, 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 de otra organización o hacer referencia a ella.
Por ejemplo, los implementadores de
dispositivos NO DEBEN agregar APIs al espacio de nombres com.google.* o similares; 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 estar empaquetadas en una biblioteca compartida de Android
para que solo las apps que las usen de forma explícita (a través del mecanismo <uses-library>
) se vean afectadas por el aumento del uso de memoria de esas APIs.

Si un implementador de dispositivos propone mejorar uno de los espacios de nombres de paquete anteriores
(por ejemplo, agregar una funcionalidad nueva útil a una API existente, o agregar 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ándares 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 máquinas virtuales
Las implementaciones de dispositivos DEBEN admitir la especificación completa del código de bytes ejecutable (DEX) de Dalvik
y la semántica de la máquina virtual de Dalvik [Recursos, 17].
Las implementaciones del dispositivo DEBEN configurar Dalvik para asignar memoria de acuerdo
con la plataforma de Android upstream, y como se especifica en la siguiente tabla. (Consulta
Sección 7.1.1 para definir el tamaño y la densidad de la pantalla).
Ten en cuenta que los valores de memoria que se especifican a continuación se consideran valores mínimos, y las
implementaciones del dispositivo PUEDEN a l ocar más memoria por aplicación.
Tamaño de la pantalla
Densidad de la pantalla
Memoria de la aplicación
pequeño  / normal / grande
ldpi / mdpi
16 MB
pequeño  / normal / grande
tvdpi / hdpi
32 MB
pequeño  / normal / grande
xhdpi
64 MB
grande
mdpi
32 MB
grande
tvdpi / hdpi
64 MB
grande
xhdpi
128 MB
3.8. Compatibilidad de la interfaz de usuario
3.8.1. Widgets
Android define un tipo de componente y la API y el ciclo de vida correspondientes que permi

a las aplicaciones exponer un "AppWidget" al usuario final [Resources, 18]. La versión de referencia de código abierto de Android
incluye una aplicación de selector que incluye indicaciones de interfaz del usuario que le permiten al usuario agregar, ver y quitar widgets de aplicaciones de la pantalla
principal.

Las implementaciones del dispositivo PUEDEN sustituir una alternativa al Selector de referencia (es decir, la pantalla principal de
). Los selectores alternativos DEBEN incluir compatibilidad integrada con AppWidgets,
y exponer indicadores de interfaz de usuario para agregar, configurar, ver y quitar
AppWidgets directamente dentro del selector. Los selectores alternativos PUEDEN omitir estos elementos de la interfaz del usuario
. Sin embargo, si se omiten, la implementación del dispositivo DEBE
proporcionar una aplicación separada a la que se pueda acceder desde el selector que les permita a los usuarios agregar,
configurar, ver y quitar widgets de apps.
Las implementaciones de dispositivos DEBEN ser capaces de renderizar widgets de 4 x 4 en el tamaño de la cuadrícula
estándar. (Consulta las Pautas de diseño de widgets de apps en la documentación del SDK
de Android [Recursos, 18] para obtener más detalles.
3.8.2. Notificaciones
Android incluye APIs que permiten a los desarrolladores notificar a los usuarios sobre eventos importantes
[Recursos, 19], mediante funciones de hardware y software del dispositivo.
Algunas APIs permi ten a las aplicaciones realizar notificaciones o atraer la atención con
hardware, en particular sonido, vibración y luz. Las implementaciones de dispositivos DEBEN
admitir notificaciones que usen funciones de hardware, como se describe en la documentación del SDK
, y en la medida de lo posible con el hardware de implementación del dispositivo.
Por ejemplo, si una implementación de dispositivo incluye un vibrador, DEBE implementar correctamente
las APIs de vibración. Si una implementación de dispositivo no tiene hardware, las
APIs correspondientes DEBEN implementarse como no-ops. Ten en cuenta que este comportamiento se detalla
más adelante en el artículo 7.
Además, la implementación DEBE renderizar correctamente todos los recursos (íconos, archivos de sonido
, etc.) que se proporcionan en las APIs [Recursos, 20] o en la guía de estilo del ícono de la barra de estado/sistema
[Recursos, 21]. Los implementadores de dispositivos PUEDEN proporcionar una experiencia del usuario
alternativa para las notificaciones que no sea la proporcionada por la implementación
de código abierto de Android de referencia. Sin embargo, esos sistemas alternativos de notificaciones DEBEN admitir los recursos de notificación
existentes, como se mencionó anteriormente.
Android 4.1 incluye compatibilidad con notificaciones enriquecidas, como Views interactivas para
notificaciones en curso. Las implementaciones de dispositivos DEBEN mostrar y ejecutar notificaciones
enriquecidas de forma adecuada, como se documenta en las APIs de Android.
3.8.3. Búsqueda
Android incluye APIs [Recursos, 22] que permiten a los desarrolladores incorporar la búsqueda en
sus aplicaciones y exponer los datos de sus aplicaciones en la búsqueda global del sistema.
En general, esta función consiste en una interfaz de usuario única y para todo el sistema
que permite a los usuarios ingresar consultas, mostrar sugerencias a medida que los usuarios escriben y mostrar
resultados. Las APIs de Android permi‐‐ten a los desarrolladores volver a usar esta interfaz para proporcionar búsquedas
dentro de sus propias apps, y también les permiten proporcionar resultados a la interfaz de usuario de búsqueda global
común.
Las implementaciones de dispositivos DEBEN incluir una interfaz de usuario de búsqueda única, compartida y en todo el sistema
capaz de hacer sugerencias en tiempo real en respuesta a la entrada del usuario. Las implementaciones de
dispositivos DEBEN implementar las APIs que permiten a los desarrolladores volver a usar esta interfaz
de usuario para proporcionar búsquedas dentro de sus propias aplicaciones. Las implementaciones de dispositivos
DEBEN implementar las APIs que permiten a las aplicaciones de terceros agregar sugerencias al
cuadro de búsqueda cuando se ejecuta en el modo de búsqueda global. Si no hay aplicaciones de terceros
instaladas que usen esta funcionalidad, el comportamiento predeterminado DEBERIA ser mostrar
resultados y sugerencias del motor de búsqueda web.
3.8.4. Toasts
Las aplicaciones pueden usar la API "Toast" (definida en [Recursos, 23]) para mostrar cadenas breves no
modales al usuario final, que desaparecen después de un breve período de tiempo. Las implementaciones de
dispositivos DEBEN mostrar notificaciones de aplicaciones a usuarios finales de alguna manera de alta
visibilidad.
3.8.5. Temas
Android proporciona "temas" como un mecanismo para que las aplicaciones apliquen estilos en
toda una actividad o aplicación. Android 3.0 presentó un nuevo tema "Holo" o "holográfico"
como un conjunto de estilos definidos para que los desarrolladores de aplicaciones los usen si quieren hacer coincidir
el aspecto y la sensación del tema Holo tal como lo define el SDK de Android [Recursos, 24]. Las implementaciones de
dispositivos NO DEBEN alterar ningún atributo del tema Holo expuesto a

aplicaciones [Recursos, 25].
Android 4.0 presentó un nuevo tema "Device Default" como un conjunto de estilos definidos para que los desarrolladores de aplicaciones los usen si quieren hacer coincidir el aspecto y la sensación del tema
del dispositivo tal como lo define el implementador del dispositivo.
Las implementaciones del dispositivo PUEDEN modificar los atributos del tema
DeviceDefault expuestos a las aplicaciones [Resources, 25].
3.8.6. Fondos de pantalla animados
Android define un tipo de componente y la API y el ciclo de vida correspondientes que permiten a las aplicaciones
exponer uno o más "Fondos de pantalla animados" al usuario final [Recursos, 26].
Los Fondos de pantalla animados son animaciones, patrones o imágenes similares con funciones 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 de forma confiable fondos de pantalla en vivo si puede ejecutar todos los fondos de pantalla
en vivo, sin limitaciones en la funcionalidad, a una tasa de fotogramas razonable sin efectos
adversos en otras aplicaciones. Si las limitaciones del hardware hacen que los fondos de pantalla
o las aplicaciones fallen, funcionen de forma inadecuada, consuman energía excesiva de la CPU o de la batería, o
se ejecuten a velocidades de fotogramas inaceptablemente bajas, se considera que el hardware es incapable de ejecutar un
fondo de pantalla en vivo. A modo de ejemplo, algunos fondos de pantalla en vivo pueden usar un contexto Open GL 1.0 o 2.0
para renderizar su contenido. El fondo de pantalla en vivo no se ejecutará de forma confiable en hardware que
no sea compatible con varios contextos de OpenGL porque el uso de un
contexto de OpenGL del fondo de pantalla en vivo puede generar conflictos con otras aplicaciones que también usan un contexto de OpenGL.
Las implementaciones de dispositivos capaces de ejecutar fondos de escritorio en vivo de forma confiable como se describió
anteriormente DEBEN implementar fondos de escritorio en vivo. Las implementaciones de dispositivos que se determinen que no
ejecutan fondos de escritorio en vivo de forma confiable como se describió anteriormente NO DEBEN implementar fondos de escritorio en vivo.
3.8.7. Visualización de aplicaciones recientes
El código fuente de Android 4.1 upstream incluye una interfaz de usuario para mostrar aplicaciones
recientes con una imagen en miniatura del estado gráfico de la aplicación en el
momento en que el usuario salió por última vez de la aplicación. Las implementaciones de dispositivos PUEDEN alterar o
eliminar esta interfaz de usuario. Sin embargo, se planea una versión futura de Android para hacer
un uso más amplio de esta funcionalidad. Se recomienda
fuertemente a las implementaciones de dispositivos que usen la interfaz de usuario upstream de Android 4.1 (o una interfaz similar basada en miniaturas) para aplicaciones recientes, de lo contrario, es posible que no sean compatibles con una
versión futura de Android.

3.8.8. Configuración de Administración de entradas
Android 4.1 incluye compatibilidad con motores de Administración de entradas. Las APIs de Android 4.1
permi‐‐ten que los IMEs personalizados de la app especifiquen parámetros de configuración ajustables por el usuario. Las implementaciones de dispositivos
DEBEN incluir una forma para que el usuario acceda a la configuración del IME en todo momento cuando se muestra un IME que
proporciona esa configuración del usuario.
3.8.9. Control remoto de la pantalla de bloqueo
Android 4.0 presentó compatibilidad con la API de Control remoto que permite a las aplicaciones multimedia
integrarse con los controles de reproducción que se muestran en una vista remota como la pantalla de bloqueo
del dispositivo [Recursos, 69]. Las implementaciones de dispositivos DEBEN incluir compatibilidad con la incorporación de controles remotos en la pantalla de bloqueo del dispositivo.

3.9 Administración de dispositivos
Android 4.1 incluye funciones que permiten a las aplicaciones orientadas a la seguridad realizar funciones de administración de dispositivos a nivel del sistema, como aplicar políticas de contraseñas o
realizar borrado remoto, a través de la API de Administración de dispositivos de Android [Recursos,
27].
Las implementaciones deben proporcionar una implementación de la clase
DevicePolicyManager [Resources, 28] y DEBEN admitir la gama completa de
políticas de administración de dispositivos definidas en la documentación del SDK de Android [Resources,
27].
Nota: Si bien algunos de los requisitos que se describieron anteriormente se declaran como "DEBEN" para
Android 4.1, la Definición de Compatibilidad para una versión futura está planificada para cambiar estos
a "DEBEN". Es decir, estos requisitos son opcionales en Android 4.1, pero se
exigirán en una versión futura. Se recomienda muy
enfáticamente a los dispositivos existentes y nuevos que ejecuten Android 4.1 que cumplan con estos requisitos en Android 4.1, de lo contrario, no
podrán alcanzar la compatibilidad con Android cuando se actualicen a la versión futura.
3.10 Accesibilidad
Android 4.1 proporciona una capa de accesibilidad que ayuda a los usuarios con discapacidades a navegar
sus dispositivos con mayor facilidad. Además, Android 4.1 proporciona APIs de plataforma que permiten a las implementaciones de servicios de accesibilidad

recibir devoluciónes de llamada para eventos del usuario y del sistema
y generar mecanismos de retroalimentación alternativos, como texto a voz, retroalimentación
táctil y navegación con bola de seguimiento o pad direccional [Recursos, 29]. Las implementaciones de dispositivos
DEBEN proporcionar una implementación del framework de accesibilidad de Android consistente
con la implementación predeterminada de Android. En particular, las implementaciones de dispositivos DEBEN
cumplir con los siguientes requisitos.
Las implementaciones de dispositivos DEBEN admitir implementaciones de servicios de accesibilidad de terceros
através de las APIs de android.accessibilityservice [Recursos,
30].
Las implementaciones de dispositivos DEBEN generar AccessibilityEvents y entregar
estos eventos a todas las implementaciones registradas de AccessibilityService de una
manera coherente con la implementación predeterminada de Android.
Las implementaciones de dispositivos DEBEN proporcionar un mecanismo accesible para el usuario para habilitar
y inhabilitar 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
activen el servicio de accesibilidad durante la configuración del dispositivo. Una implementación de código abierto
de un servicio de accesibilidad está disponible en el proyecto Eyes Free [Recursos, 31].
3.11 Texto a voz
Android 4.1 incluye APIs que permiten a las aplicaciones usar servicios de texto a voz (TTS)
y permiten a los proveedores de servicios proporcionar implementaciones de servicios de TTS
[Recursos, 32].Las implementaciones del dispositivo DEBEN cumplir con estos requisitos relacionados con
el marco de trabajo de TTS de Android:
Las implementaciones del dispositivo DEBEN ser compatibles con las APIs del marco de trabajo de TTS de Android y
DEBEN incluir un motor de TTS compatible con los idiomas disponibles en el
dispositivo. Ten en cuenta que el software de código abierto de Android upstream incluye una implementación completa del motor de TTS con funciones.
Las implementaciones de dispositivos DEBEN admitir la instalación de motores de TTS de terceros.
Las implementaciones de dispositivos DEBEN proporcionar una interfaz accesible para el usuario que permita a
los usuarios seleccionar un motor de TTS para usar a nivel del sistema.

4. Compatibilidad de empaquetado de aplicaciones
Las implementaciones de dispositivos DEBEN instalar y ejecutar archivos ".apk" de Android tal como los genera la herramienta
"aapt" incluida en el SDK oficial de Android [Recursos, 33].
Las implementaciones de dispositivos NO DEBEN extender ni el formato .apk [Recursos, 34], el manifiesto
de Android [Recursos, 35], el código de bytes de Dalvik [Recursos, 17] ni el código de bytes de renderscript
de tal manera que eviten que esos archivos se instaleny se ejecuten correctamente
en otros dispositivos compatibles.Los implementadores de dispositivos DEBEN usar la implementación upstream de referencia de Dalvik, y el sistema de administración de paquetes
de la implementación de referencia.

5. Compatibilidad multimedia
Las implementaciones de dispositivos DEBEN incluir al menos una forma de salida de audio, como
bocinas, conector para auriculares, conexión a bocinas externas, etc.
5.1. Códecs multimedia
Las implementaciones del dispositivo DEBEN admitir los formatos multimedia principales especificados en la documentación del SDK de
Android [Recursos, 58] , excepto cuando se permita de forma explícita en este
documento. Específicamente, las implementaciones de dispositivos DEBEN admitir los formatos multimedia,
codificadores, decodificadores, tipos de archivos y formatos de contenedores 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
declaración de que estos códecs no estén sujetos a patentes de terceros.
Se aconseja a quienes pretendan usar este código fuente en productos de hardware o software que
las implementaciones de este código, incluidas las de software de código abierto
o shareware, puedan requerir licencias de patentes de los titulares de patentes relevantes.
Ten en cuenta que estas tablas no mencionan los requisitos de bitrate específicos para la mayoría de los codecs de video
porque el hardware actual de los dispositivos no necesariamente admite bitrates que se asignan
exactamente a los bitrates requeridos especificados por los estándares relevantes. En cambio, las implementaciones de
dispositivos DEBEN admitir el mayor bitrate práctico en el hardware, hasta

los límites definidos por las especificaciones.

Tipos de archivo /
Formato /
Tipo
Codificación
Decodificación
Detalles
Contenedor
Códec
Formatos
Compatibilidad con
OBLIGATORIO
mono/estéreo/5.0/5.1*
MPEG-4
Obligatorio para implementaciones de dispositivos
contenido con
Perfil AAC
que incluya hardware de micrófono
OBLIGATORIO
muestreo estándar
(AAC LC)
y define
3GPP
tarifas de 8 a 48
android.hardware.microphone.
(.3gp)
kHz.
Compatibilidad con
(.mp4,
MPEG-4
mono/estéreo/5.0/5.1*
.m4a)
contenido HE AAC
con
ADTS sin procesar

REQUERIDO
Perfil
muestreo estándar
AAC (.aac,
(AAC+)
velocidades de 16 a 48
decodifica en
kHz.

Android
3.1 y versiones posteriores:
Compatibilidad con
MPEG-4
OBLIGATORIA para la codificación
del dispositivo en
mono/estéreo/5.0/5.1*
implementaciones de HE AAC v2
que incluyan
contenido
de Android con
hardware de micrófono
Profile
y

4.0 y versiones posteriores, muestreo estándar
(definido
como
no
tasas de 16 a 48
AAC+)
android.hardware.microphone
compatible)
kHz.
MPEG-TS
MPEG-4
(.ts, no
audio
OBLIGATORIO para el dispositivo
Compatibilidad con
implementaciones
de tipo de objeto
que incluyan
contenido mono/estéreo
Android
ER AAC
hardware de micrófono y
OBLIGATORIO
con estándar
3.0+)
ELD
define
las tasas de muestreo de
(Enhanced
android.hardware.microphone
16 a 48 kHz.
Retraso bajo
AAC)
OBLIGATORIO
Obligatorio para implementaciones de dispositivos
De 4.75 a 12.2 Kbps
AMR-NB
que incluyan hardware de micrófono
OBLIGATORIO
3GPP (.3gp)
con muestreo a 8 kHz
y define
android.hardware.microphone.
OBLIGATORIO
Obligatorio para implementaciones de dispositivos
9 tasas de 6.60
AMR-WB
que incluyan hardware de micrófono
OBLIGATORIO
kbit/s a 23.85 kbit/s
3GPP (.3gp)
y define
con muestreo a 16 kHz
android.hardware.microphone.
Mono/estéreo (sin
multicanal).
Audio
Tasas de muestreo de hasta
48 kHz (pero se recomienda hasta
44.1 kHz en
dispositivos con salida de 44.1
OBLIGATORIA
FLAC

kHz, ya que el reductor de muestreo de 48
FLAC (.flac) solo
(Android 3.1 y versiones posteriores)
a 44.1 kHz
no incluye un filtro de paso bajo).

Se recomienda
16 bits. No se aplicó
ninguna interpolación para 24
bits.
Mono/estéreo 8-
320 Kbps constante
MP3

OBLIGATORIO
MP3 (.mp3)
(CBR) o tasa de bits
variable (VBR)
Tipo 0 y
MIDI Tipo 0 y 1.
1 (.mid,
DLS versión 1 y
.xmf, .mxmf)
2. XMF y Mobile
RTTTL/RTX
MIDI

OBLIGATORIO
XMF. Compatibilidad con los formatos de tono
(.rtttl, .rtx)

OTA (.ota)
RTTTL/RTX, OTA,
iMelody
y iMelody
(.imy)

Ogg (.ogg)
Vorbis

OBLIGATORIO

Matroska
(.mkv)
PCM lineal de 8 bits y 16 bits** (tasas
hasta el límite del
hardware).Los dispositivos
DEBEN ser compatibles con
PCM/WAVE
OBLIGATORIO
OBLIGATORIO
WAVE (.wav)
tasas de muestreo para
grabación PCM sin procesar
a 8000,16000 y
44100 Hz
de frecuencia
JPEG
OBLIGATORIO
OBLIGATORIO
Base+progresiva
JPEG (.jpg)
GIF

OBLIGATORIO

GIF (.gif)
Imagen
PNG
OBLIGATORIO
OBLIGATORIO

PNG (.png)
BMP

OBLIGATORIO

BMP (.bmp)
WEBP
OBLIGATORIO
OBLIGATORIO

WebP (.webp)
OBLIGATORIO
Obligatorio para implementaciones de dispositivos
3GPP
que incluyan hardware de cámara y
(.3gp)
H.263
OBLIGATORIO

define android.hardware.camera
MPEG-4
o
(.mp4)
android.hardware.camera.front.

3GPP
(.3gp)
OBLIGATORIO
MPEG-4
(.mp4)
OBLIGATORIO para implementaciones de dispositivos
MPEG-TS
que incluyan hardware de cámara y
Perfil de Baseline
Video
H.264 AVC
OBLIGATORIO
(.ts, AAC
define android.hardware.camera
(BP)
solo audio,
o
no
android.hardware.camera.front.
buscable,
Android
3.0+)
MPEG-4

OBLIGATORIO

3GPP (.3gp)
SP
WebM (.webm)
OBLIGATORIO
y Matroska
VP8

(Android

(.mkv, Android
2.3.3+)
4.0+)
*Nota: Solo se requiere la conmutación a mono de contenido 5.0/5.1; la grabación o renderización de más de 2
canales es opcional. **Nota: La captura de PCM lineal de 16 bits es obligatoria. No es obligatoria la captura de PCM
lineal de 8 bits.
5.2 Codificación de video
Las implementaciones de dispositivos Android que incluyen una cámara posterior y declaran
android.hardware.camera DEBEN ser compatibles con los siguientes perfiles de codificación de video.
HD (cuando el hardware

SD (baja calidad) SD (alta calidad)
lo admite)
Códec de video
Códec de video H.264 Baseline
H.264 Baseline

Grabación de audio
Cuando una aplicación usó la API android.media.AudioRecord para comenzar a grabar
una transmisión de audio, las implementaciones de dispositivos que incluyen hardware de micrófono y
declaran android.hardware.microphone DEBEN obtener muestras y grabar audio con cada uno de
estos comportamientos:
El dispositivo DEBE exhibir características de amplitud aproximadamente planas en relación con la frecuencia
; específicamente, ±3 dB, de 100 Hz a 4000 Hz.
La sensibilidad de entrada de audio DEBE configurarse de tal manera que una fuente de nivel de potencia de sonido
(SPL) de 90 dB a 1000 Hz produzca un RMS de 2500 para muestras de 16 bits.
Los niveles de amplitud de PCM DEBEN seguir de forma lineal los cambios de SPL de entrada en al menos un
rango de 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 menor al 1% para 1 kHz a 90 dB SPL de nivel
de entrada.
Además de las especificaciones de grabación anteriores, cuando una aplicación haya iniciado
la grabación de una transmisión de audio con la fuente de audio
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION, el procesamiento de reducción de ruido, si está presente, DEBE estar inhabilitado.
El control de ganancia automático, si está presente, DEBE estar inhabilitado.

Nota: Si bien algunos de los requisitos que se describieron anteriormente se declaran como "DEBEN" para
Android 4.1, la Definición de Compatibilidad para una versión futura está planificada para cambiar estos
a "DEBEN". Es decir, estos requisitos son opcionales en Android 4.1, pero se
exigirán en una versión futura. Se recomienda muy
enfáticamente a los dispositivos existentes y nuevos que ejecuten Android 4.1 que cumplan con estos requisitos en Android 4.1, de lo contrario, no
podrán alcanzar la compatibilidad con Android cuando se actualicen a la versión futura.
5.4. Latencia de audio
La latencia de audio se define ampliamente como el intervalo entre el momento en que una aplicación solicita
una operación de reproducción o registro de audio, y el momento en que la implementación del dispositivo real y
comienza la operación. Muchas clases de aplicaciones dependen de latencia corta para lograr
efectos en tiempo real, como efectos de sonido o comunicación VOIP. Las implementaciones de dispositivos
que incluyan hardware de micrófono y declaren android.hardware.microphone
DEBEN cumplir con todos los requisitos de latencia de audio que se describen en esta sección. Consulta el artículo 7
para obtener detalles sobre las condiciones en las que las implementaciones de dispositivos pueden omitir el hardware del micrófono.

Para los fines de esta sección:
La "latencia de salida fría" se define como el intervalo entre el momento en que una aplicación
solicita la reproducción de audio y el momento en que el sonido comienza a reproducirse, cuando el sistema de audio
estuvo inactivo y apagado antes de la solicitud
La"latencia de salida caliente" se define como el intervalo entre el momento en que una aplicación
solicita la reproducción de audio y el momento en que el sonido comienza a reproducirse, cuando el sistema de audio
se usó recientemente, pero actualmente está inactivo (es decir, silencioso)
La"latencia de salida continua" se define como el intervalo entre el momento en que una
aplicación ejecuta una muestra para que se reproduzca y el momento en que el altavoz físico y reproduce
el sonido correspondiente, mientras el dispositivo está reproduciendo audio
La"latencia de entrada fría" se define como el intervalo entre el momento en que una aplicación
solicita la grabación de audio y el momento en que se envía la primera muestra a la
aplicación a través de su retroacción de cal, cuando el sistema de audio y el micrófono estuvieron
inactivos y apagados antes de la solicitud
La"latencia de entrada continua" se define como cuando ocurre un sonido ambiente y
cuando la muestra correspondiente a ese sonido se envía a una aplicación
de grabación a través de su retroacción de cal, mientras el dispositivo está en modo de grabación
Con las definiciones anteriores, las implementaciones de dispositivos DEBEN exhibir cada una de estas
propiedades:
latencia de salida fría de 100 mil microsegundos o menos
latencia de salida caliente de 10 mil microsegundos o menos
latencia de salida continua de 45 mil microsegundos o menos
latencia de entrada fría de 100 mil microsegundos o menos
latencia de entrada continua de 50 mil microsegundos o menos
Nota: Si bien los requisitos que se describen anteriormente se indican como "DEBEN" para Android 4.1,

se planifica que la definición de compatibilidad para una versión futura los cambie a "DEBEN".
Es decir, estos requisitos son opcionales en Android 4.1, pero serán obligatorios en una versión
Se recomienda muy fuertemente
a los dispositivos existentes y nuevos que ejecuten Android 4.1 que cumplan con estos requisitos en Android 4.1, de lo contrario, no podrán
alcanzar la compatibilidad con Android cuando se actualicen a la versión futura.
Si una implementación de dispositivo cumple con los requisitos de esta sección, PUEDE informar
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, 37]
Por el contrario, si la implementación del dispositivo no cumple con estos requisitos, debe
NO informar la compatibilidad con audio de latencia baja.
5.5. Protocolos de red
Los dispositivos DEBEN ser compatibles con 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, 58]. Específicamente, los dispositivos
DEBEN admitir los siguientes protocolos de red multimedia:
RTSP (RTP, SDP)
Transmisión progresiva de HTTP(S)
Protocolo en borrador de transmisión en vivo de HTTP(S), versión 3 [Recursos, 59]
6. Compatibilidad con herramientas para desarrolladores
Las implementaciones de dispositivos DEBEN admitir las herramientas para desarrolladores de Android que se proporcionan en el
SDK de Android. Específicamente, los dispositivos compatibles con Android DEBEN ser compatibles con lo siguiente:
Android Debug Bridge (conocido como adb) [Recursos, 33]
Las implementaciones de dispositivos DEBEN admitir todas las funciones de adb como se documenta en el
SDK de Android. El daemon 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
.
Servicio de supervisión de depuración de Dalvik (conocido como ddms) [Recursos, 33]
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 DEBERIA estar inactiva de fa
vor, pero DEBERIA ser compatible siempre que el usuario haya activado el puente de depuración de Android
, como se mencionó anteriormente.
Monkey [Recursos, 36]
Las implementaciones de dispositivos DEBEN incluir el framework de Monkey y hacerlo
disponible para que las aplicaciones lo usen.
La mayoría de los sistemas basados en Linux y Apple Macintosh reconocen dispositivos Android
con las herramientas estándares del SDK de Android, sin compatibilidad adicional. Sin embargo, los sistemas Microsoft
Windows típicamente requieren un controlador para dispositivos Android nuevos. (por ejemplo,
los IDs de proveedor nuevos y, a veces, los IDs de dispositivo nuevos requieren controladores USB personalizados para
sistemas Windows). Si la herramienta adb no reconoce una implementación de dispositivo como la que se proporciona en el SDK estándar de Android, los implementadores de dispositivos DEBEN proporcionar controladores
de Windows para permitir que los desarrolladores se conecten al dispositivo con el protocolo adb.
Estos
controladores SE DEBEN proporcionar para Windows XP, Windows Vista, y Windows 7, en las versiones
de 32 bits y 64 bits.
7. Compatibilidad de hardware
Si un dispositivo incluye un componente de hardware 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 declara como opcional y la implementación del dispositivo no
posee ese componente,
las definiciones de clase completas (como se documenta en el SDK) para las APIs del componente
DEBEN seguir estando presentes
los comportamientos de la API DEBEN implementarse como no-ops de una manera razonable
los métodos de API DEBEN mostrar valores nulos cuando la documentación del SDK lo permita
los métodos de API DEBEN mostrar implementaciones sin operaciones de clases cuando la documentación del SDK no permita valores nulos
los métodos de API NO DEBEN generar excepciones que no se documenten 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-ops razonables.

Las implementaciones de dispositivos DEBEN informar con precisión la información de configuración del hardware
a través de los métodos getSystemAvailableFeatures() y hasSystemFeature(String)
en la clase android.content.pm.PackageManager. [Resources, 37]
7.1. Pantalla y gráficos
Android 4.1 incluye funciones que ajustan automáticamente los recursos de la aplicación y los diseños de la IU
de forma adecuada para el dispositivo, para garantizar que las aplicaciones de terceros se ejecuten bien en una
variedad de parámetros de configuración de hardware [Recursos, 38]. Los dispositivos DEBEN implementar correctamente
estas APIs y comportamientos, como se detallan en esta sección.
Las unidades a las que hacen referencia los requisitos de esta sección se definen de la siguiente manera:
"Tamaño diagonal físico" es la distancia en pulgadas entre dos esquinas opuestas
de la porción iluminada de la pantalla.
"dpi" (que significa "puntos por pulgada") es la cantidad de píxeles que comprende un rango
horizontal o vertical lineal de 1". Cuando se enumeran los valores de dpi, tanto los dpi horizontales como los
verticales deben estar dentro del rango.
"Relación de aspecto" es la relación entre la dimensión más larga de la pantalla y la dimensión más corta
. Por ejemplo, una pantalla de 480 x 854 píxeles sería 854 / 480 =
1.779, o alrededor de "16:9".
Un "píxel independiente de la densidad" o ("dp") es la unidad de píxel virtual normalizada a una pantalla de 160
dpi, que se calcula de la siguiente manera: píxeles = dps * (densidad / 160).
7.1.1. Configuración de la pantalla
Tamaño de la pantalla
El framework de la IU de Android admite una variedad de diferentes tamaños de pantalla y permite a las
aplicaciones consultar el tamaño de la pantalla del dispositivo (también conocido como "diseño de pantalla") a través de
android.content.res.Configuration.screenLayout con la
SCREENLAYOUT_SIZE_MASK. Las implementaciones de dispositivos DEBEN informar el tamaño correcto de la pantalla
como se define en la documentación del SDK de Android [Recursos, 38] y determinado por
la plataforma de Android upstream. Específicamente, las implementaciones de dispositivos deben informar el
tamaño de pantalla correcto según las siguientes dimensiones de pantalla lógicas de píxeles (dp) dependentes de la densidad.

Los dispositivos DEBEN tener tamaños de pantalla de al menos 426 dp x 320 dp ('pequeña ')
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 un tamaño de pantalla 'grande' DEBEN tener tamaños de pantalla de al menos 640
dp x 480 dp
Los dispositivos que informan un tamaño de pantalla 'extragrande' DEBEN tener tamaños de pantalla de al menos 960
dp x 720 dp
Además, los dispositivos DEBEN tener tamaños de pantalla de al menos 2.5 pulgadas en tamaño diagonal físico
.
Los dispositivos NO DEBEN cambiar el tamaño de pantalla informado en ningún momento.
Las aplicaciones opcionales indican qué tamaños de pantalla admiten a través del atributo <supports-
screens> en el archivo AndroidManifest.xml. Las implementaciones de dispositivos DEBEN
respetar correctamente la compatibilidad declarada de las aplicaciones para pantallas pequeñas, normales, grandes y extragrandes
, como se describe en la documentación del SDK de Android.
Relación de aspecto de la pantalla
La relación de aspecto DEBE ser de entre 1.3333 (4:3) y 1.85 (16:9).
Densidad de pantalla
El framework de IU de Android define un conjunto de densidades lógicas estándares para ayudar a los
desarrolladores de aplicaciones a orientar los recursos de aplicación. Las implementaciones de dispositivos DEBEN
informar 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 en esta densidad estándar
.
120 dpi, conocido como 'ldpi'
160 dpi, conocido como 'mdpi'
213 dpi, conocido como 'tvdpi'
240 dpi, conocido como 'hdpi'
320 dpi, conocido como 'xhdpi'
480 dpi, conocido como 'xxhdpi'
Las implementaciones de dispositivos DEBEN definir la densidad estándar del framework de Android que
es numérica y más cercana a 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 compatible.

Si la densidad del framework estándar de Android que es numérica y más cercana a la densidad física genera un tamaño de pantalla
que es menor que el tamaño de pantalla compatible más pequeño (ancho de 320 dp),las implementaciones de dispositivos DEBEN informar la densidad
del framework estándar de Android siguiente más baja.

7.1.2. Métricas de pantalla
Las implementaciones de dispositivos DEBEN informar valores correctos para todas las métricas de pantalla definidas en
android.util.DisplayMetrics [Resources, 39].
7.1.3. Orientación de la pantalla
Los dispositivos DEBEN admitir la orientación dinámica de las aplicaciones para la orientación de la pantalla vertical o
horizontal. Es decir, el dispositivo debe respetar la solicitud
de la aplicación para una orientación de pantalla específica. Las implementaciones del dispositivo PUEDEN seleccionar la orientación
vertical o horizontal como la predeterminada.
Los dispositivos DEBEN informar el valor correcto de la orientación actual del dispositivo, siempre que se consulte a través de android.content.res.Configuration.orientation,
android.view.Display.getOrientation(), o otras APIs.

Los dispositivos NO DEBEN cambiar el tamaño ni la densidad de la pantalla informada cuando cambian la orientación
.
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.
7.1.4. Aceleración de gráficos 2D y 3D
Las implementaciones de dispositivos DEBEN ser compatibles con OpenGL ES 1.0 y 2.0, como se especifica
y se detallan en la documentación del SDK de Android. Las implementaciones del dispositivo TAMBIÉN DEBEN
admitir Android Renderscript, como se detalló en la documentación del SDK de Android
[Recursos, 8].
Las implementaciones de dispositivos TAMBIÉN DEBEN identificarse correctamente como compatibles con
OpenGL ES 1.0 y 2.0. Es decir:
Las APIs administradas (como a través del método GLES10.getString()) DEBEN informar
compatibilidad con OpenGL ES 1.0 y 2.0
Las APIs nativas de OpenGL C/C++ (es decir, las disponibles para las apps a través de
libGLES_v1CM.so, libGLES_v2.so, o libEGL.so) DEBEN informar compatibilidad con
OpenGL ES 1.0 y 2.0.
Las implementaciones de dispositivos PUEDEN implementar cualquier extensión deseada de OpenGL ES.
Sin embargo, las implementaciones de dispositivos DEBEN informar a través de las APIs administradas y
nativas de OpenGL ES las cadenas de extensión que sí son compatibles, y viceversa, NO DEBEN informar
cadenas de extensión que no son compatibles.
Ten en cuenta que Android 4.1 incluye compatibilidad con aplicaciones para opcionalmente especificar que
requieren formatos específicos de compresión de texturas OpenGL. Estos formatos son típicos y
específicos del proveedor. Android 4.1 no requiere implementaciones de dispositivos para implementar
ningún formato específico de compresión de texturas. Sin embargo, DEBEN informar con precisión cualquier
formato de compresión de texturas que sí admitan, a través del método getString() en la API de
OpenGL.
Android 4.1 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 a través del uso de una etiqueta de manifiesto android:hardwareAccelerated o una llamada a la API
directa [Recursos, 9].
En Android 4.1, las implementaciones de dispositivos DEBEN habilitar la aceleración de hardware de forma
predeterminada, y DEBEN inhabilitar la aceleración de hardware si el desarrollador lo solicita a través de
la configuración android:hardwareAccelerated="false" o la inhabilitación de la aceleración de hardware
directamente a través de las APIs de Android View.
Además, las implementaciones de dispositivos DEBEN exhibir un comportamiento coherente con la documentación del SDK de Android
sobre la aceleración de hardware [Recursos, 9].
Android 4.1 incluye un objeto TextureView que permite a los desarrolladores integrar directamente texturas OpenGL ES aceleradas por hardware como objetivos de renderización en una jerarquía de IU.
Las implementaciones de dispositivos DEBEN admitir la API de TextureView, y DEBEN exhibir un comportamiento

consistente con la implementación de Android upstream.

7.1.5. Modo de compatibilidad de aplicaciones heredadas
Android 4.1 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 beneficiar a las aplicaciones
heredadas que no se desarrollaron para versiones antiguas 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 de
, y NO DEBEN alterar el comportamiento del modo de compatibilidad de
.

7.1.6. Tipos de pantallas
Las pantallas de implementación de dispositivos se clasifican como uno de dos tipos:
Implementaciones de pantallas de píxeles fijos: la pantalla es un panel único que admite
solo un ancho y una altura de píxeles. Por lo general, la pantalla es física y está integrada
con el dispositivo. Entre los ejemplos, se incluyen teléfonos móviles, tablets y más.
Implementaciones de pantallas de píxeles variables: la implementación del dispositivo no tiene una
pantalla integrada y incluye un puerto de salida de video como VGA, HDMI o un
puerto inalámbrico para la pantalla, o tiene una pantalla integrada que puede cambiar las dimensiones de los
píxeles. Algunos ejemplos son televisiones, decodificadores, etcétera.
Implementaciones de dispositivos con píxeles fijos
Las implementaciones de dispositivos con píxeles fijos PUEDEN usar pantallas de cualquier dimensión de píxeles,
siempre que cumplan con los requisitos definidos en esta Definición de Compatibilidad.
Las implementaciones de píxeles fijos PUEDEN incluir un puerto de salida de video para usar con una pantalla
externa. Sin embargo, si esa pantalla se usa para ejecutar apps, el dispositivo DEBE cumplir
con los siguientes requisitos:
El dispositivo DEBE informar la misma configuración de pantalla y las métricas de pantalla, como
se detallan en los artículos 7.1.1 y 7.1.2, como la pantalla de píxeles fijos.
El dispositivo DEBE informar la misma densidad lógica que la pantalla de píxeles fijos.
El dispositivo DEBE informar dimensiones de pantalla que sean las mismas que la pantalla de píxeles fijos, o muy próximas
a ellas.
Por ejemplo, una tablet de 7" de diagonal con una resolución de 1024 x 600 píxeles se
considera una implementación de pantalla mdpi grande de píxeles fijos. Si contiene un puerto de salida de video
que se muestra en 720p o 1080p, la implementación del dispositivo DEBE ajustar la salida
de modo que las aplicaciones solo se ejecuten en una ventana mdpi grande, independientemente de
si la pantalla de píxeles fijos o el puerto de salida de video están en uso.
Implementaciones de dispositivos con píxeles variables
Las implementaciones de dispositivos con píxeles variables DEBEN admitir una o ambas de las resoluciones 1280 x 720 o
1920 x 1080 (es decir, 720p o 1080p). Las implementaciones de dispositivos con pantallas
de píxeles variables NO DEBEN admitir ningún otro modo ni configuración de pantalla. Las
implementaciones de dispositivos con pantallas de píxeles variables PUEDEN cambiar la configuración de la pantalla o el
modo durante el tiempo de ejecución o el inicio. Por ejemplo, un usuario de una consola decodificadora puede reemplazar una pantalla
720p por una pantalla 1080p, y la implementación del dispositivo puede ajustar
según corresponda.
Además, las implementaciones de dispositivos con dimensiones de píxeles variables están restringidas a
720p o 1080p en Android 4.1, y DEBEN configurarse para informar el tamaño de la pantalla y los
buckets de densidad como se mencionó anteriormente.

7.1.7. Tecnología de pantalla
La plataforma de Android incluye APIs que permiten a las aplicaciones renderizar gráficos complejos en
la pantalla. Los dispositivos DEBEN ser compatibles con todas estas APIs como se define en el SDK de Android
, a menos que se especifique lo contrario en este documento. Específicamente:
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 utiliza DEBE tener una relación de aspecto (PAR) de píxeles entre 0.9

y 1.1. Es decir, la relación de aspecto de los píxeles DEBE ser cercana a cuadrada (1.0) con una tolerancia del 10%
.
7.2. Dispositivos de entrada
7.2.1. Teclado
Implementaciones del dispositivo:
DEBEN incluir compatibilidad con el framework de Administración de entradas (que permite a los desarrolladores de terceros crear motores de Administración de entradas, es decir, teclados en pantalla) como
se detallan en http://developer.android.com
DEBEN proporcionar al menos una implementación de teclado en pantalla (independientemente de si hay un teclado físico)
PUEDEN incluir implementaciones adicionales de teclado en pantalla
PUEDEN incluir un teclado en hardware
NO DEBEN incluir un teclado en hardware que no coincida con uno de los formatos
especificados en android.content.res.Configuration.keyboard [Resources, 40]
(es decir, QWERTY o 12 teclas)
7.2.2.

Navegación sin toque
Implementaciones de dispositivos:
PUEDEN omitir una opción de navegación sin toque (es decir, pueden omitir un trackball, un pad direccional o una
rueda).
DEBEN informar el valor correcto para
android.content.res.Configuration.navigation [Resources, 40].
DEBEN proporcionar un mecanismo de interfaz de usuario alternativo razonable para la
selección y edición de texto, compatible con los motores de administración de entrada. El software de código abierto de Android upstream incluye un mecanismo de selección
adecuado para usarse con dispositivos que no tienen entradas de navegación no táctiles.

7.2.3. Teclas de navegación
Las funciones Inicio, Menú y Atrás son esenciales para el paradigma de navegación de Android
. Las implementaciones del dispositivo DEBEN hacer que estas funciones estén disponibles para el usuario
en todo momento cuando se ejecuten aplicaciones. Estas funciones PUEDEN implementarse a través de
botones físicos dedicados (como botones mecánicos o capacitivos táctiles), o PUEDEN
implementarse con teclas de software dedicadas, gestos, panel táctil, etc. Android
4.1 admite ambas implementaciones.
Android 4.1 presenta compatibilidad con la acción de asistencia [Resources, 63]. Las
implementaciones del dispositivo DEBEN hacer que la acción de asistencia esté disponible para el usuario en todo momento cuando se ejecuten aplicaciones.
Esta función PUEDE implementarse a través de llaves de hardware o software
.
Las implementaciones de dispositivos PUEDEN usar una porción distinta de la pantalla para mostrar las
teclas de navegación, pero si es así, DEBEN cumplir con estos requisitos:
Las teclas de navegación de la implementación del dispositivo DEBEN usar una porción distinta de la
pantalla, no disponible para las aplicaciones, y NO DEBEN ocultar ni interferir de otra manera con la porción de la pantalla disponible para las aplicaciones.
Las implementaciones de dispositivos DEBEN hacer disponible una porción de la pantalla para
aplicaciones que cumpla con los requisitos definidos en el artículo 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 no invasivo
de"perfil bajo" (p. ej., atenuado) 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.
La implementación de dispositivos DEBEN presentar una clave de menú a las aplicaciones cuando
targetSdkVersion <= 10 y NO DEBEN presentar una clave de menú cuando
targetSdkVersion > 10.
Las implementaciones de dispositivos DEBEN poner a disposición una porción de la pantalla a las
aplicaciones que cumplan con los requisitos definidos en el artículo 7.1.1.
7.2.4.Entrada de pantalla táctil
Las implementaciones de dispositivos DEBEN tener un sistema de entrada de puntero de algún tipo (
similar a un mouse o táctil). Sin embargo, si una implementación de dispositivo no admite un sistema de entrada de puntero
, NO DEBE informar la constante de función android.hardware.touchscreen ni
android.hardware.faketouch. Las implementaciones de dispositivos que

incluyen un sistema de entrada de punteros:
DEBEN admitir punteros con seguimiento completo y independiente, si el sistema de entrada del dispositivo
admite varios punteros
DEBEN informar el valor de android.content.res.Configuration.touchscreen
[Resources, 40] correspondiente al tipo de la pantalla táctil específica en el
dispositivo
Android 4.0 incluye compatibilidad con una variedad de pantallas táctiles, paneles táctiles y dispositivos de entrada táctil
falsos. Las implementaciones de dispositivos con pantallas táctiles están asociadas con una
pantalla [Recursos, 71] de modo que el usuario tenga la impresión de manipular directamente los elementos
en la pantalla. Dado que el usuario toca directamente la pantalla, el sistema no
requiere ningún indicador adicional para indicar los objetos que se manipulan. En
contraste, una interfaz táctil falsa proporciona un sistema de entrada del usuario que se aproxima a un
subconjunto de funciones de pantalla táctil. Por ejemplo, un mouse o control remoto que controla
un cursor en pantalla se aproxima al toque, pero requiere que el usuario primero apunte o enfóquese
y, luego, haga clic. Varios dispositivos de entrada, como el mouse, el panel táctil, el mouse aéreo basado en giroscopio,
el puntero giroscópico, el joystick y el panel táctil multitáctil, pueden admitir interacciones táctiles falsas.
Android 4.0 incluye la constante de función android.hardware.faketouch, que
corresponde a un dispositivo de entrada no táctil de alta fidelidad (es decir, basado en un puntero), como un
mouse o un panel táctil que puede emular adecuadamente la entrada táctil (incluida la compatibilidad con gestos
básicos) y que indica que el dispositivo admite un subconjunto emulado de la funcionalidad de la
pantalla táctil. Las implementaciones de dispositivos que declaran la función de toque falso
DEBEN cumplir con los requisitos de toque falso que se indican en el artículo 7.2.5.
Las implementaciones de dispositivos DEBEN informar la función correcta que corresponde al tipo de
entrada que se usa. Las implementaciones de dispositivos que incluyan una pantalla táctil (de un solo toque o mejor)
DEBEN informar la constante de función de la plataforma android.hardware.touchscreen. Las
implementaciones de dispositivos que informan la constante de función de la plataforma
android.hardware.touchscreen TAMBIÉN DEBEN informar la constante de función de la plataforma
android.hardware.faketouch. Las implementaciones de dispositivos que no incluyan una
pantalla táctil (y dependan solo 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 toque
falso en el artículo 7.2.5.
7.2.5. Entrada de toque falso
Las implementaciones de dispositivos que declaran compatibilidad con android.hardware.faketouch
DEBEN informar las posiciones absolutas X e Y de la pantalla de la ubicación del puntero y
mostrar un puntero visual en la pantalla[Resources, 70]
DEBEN informar el evento de toque con el código de acción [Resources, 70] que especifica el
cambio de estado que ocurre en el puntero going down or up on the screen
[Resources, 70]
DEBEN admitir el puntero abajo y arriba en un objeto en la pantalla, lo que permite
a los usuarios emular tocar en un objeto en la pantalla
DEBEN admitir el puntero abajo, el puntero arriba, el puntero abajo y, luego, el puntero arriba en el mismo
lugar en un objeto en la pantalla dentro de un umbral de tiempo, lo que permite a los usuarios
emular un toque doble en un objeto en la pantalla [Resources, 70]
DEBEN admitir el puntero abajo en un punto arbitrario en la pantalla, el movimiento del puntero a
cualquier otro punto arbitrario en la pantalla, seguido de un puntero arriba, lo que permite a los
usuarios emular un arrastre de toque
DEBEN admitir el puntero abajo y, luego, permitir que los usuarios muevan rápidamente el objeto a una
posición diferente en la pantalla y, luego, el puntero arriba en la pantalla, lo que permite a los
usuarios lanzar 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 DEBEN también admitir el seguimiento
distinto de dos o más entradas de puntero independientes.
7.2.6. Micrófono
Las implementaciones del dispositivo 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 como no-ops, según el Artículo 7.
Por el contrario, las implementaciones de dispositivos que sí poseen un micrófono:
DEBEN informar la constante de la función android.hardware.microphone
DEBEN cumplir con los requisitos de calidad de audio en el Artículo 5.4
DEBEN cumplir con los requisitos de latencia de audio en el Artículo 5.5
7.3. Sensores

Android 4.1 incluye APIs para acceder a una variedad de tipos de sensores. Las implementaciones generales de los dispositivos PUEDEN omitir estos sensores, como se indica en las siguientes subsecciones
.
Si un dispositivo incluye un tipo de sensor 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. Por ejemplo, las implementaciones de dispositivos:
DEBEN informar con precisión la presencia o ausencia de sensores según la clase
android.content.pm.PackageManager. [Resources, 37]
Debe mostrar una lista precisa de los sensores compatibles a través de
SensorManager.getSensorList() y métodos similares.
Debe comportarse de forma razonable para todas las otras APIs de sensores (por ejemplo, mostrando verdadero
o falso según corresponda cuando las aplicaciones intenten registrar objetos de escucha, no llamar
a objetos de escucha de sensores cuando los sensores correspondientes no están presentes, etc.)
Debe informar todas las mediciones de sensores con el Sistema Internacional de Unidades (es decir, métrico) para cada tipo de sensor, tal como se define en la documentación del SDK de Android
[Recursos, 41]
La lista anterior no es exhaustiva. El comportamiento documentado del SDK de Android es
la fuente autorizada.

Algunos tipos de sensores son sintéticos, es decir, se pueden derivar de datos proporcionados por
uno o más otros 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 incluyan los sensores físicos requisitos previos.
Las APIs de Android 4.1 presentan una noción de un sensor "en tiempo real", que es uno que
muestra datos de forma continua, en lugar de solo cuando los datos cambian. Las
implementaciones del dispositivo DEBEN proporcionar muestras de datos periódicas para cualquier API
que indique la documentación del SDK de Android 4.1 para ser un sensor de transmisión.
7.3.1. Acelerómetro
Las implementaciones del dispositivo DEBEN incluir un acelerómetro de 3 ejes. Si una implementación de
dispositivo incluye un accelerómetro de 3 ejes, debe poder proporcionar eventos a 120 Hz o más.
Ten en cuenta que, si bien la frecuencia del accelerómetro anterior se indica como "DEBEN" para Android 4.1, la
Definición de Compatibilidad para una versión futura está planificada para cambiar esto a
"DEBEN".
Es decir, estos estándares son opcionales en Android 4.1, pero serán
obligatorios en versiones futuras. Se recomienda
muy enfáticamente a los dispositivos existentes y nuevos que ejecuten Android 4.1 que cumplan con estos requisitos en Android 4.1 para que puedan actualizarse a las versiones futuras de la plataforma.
DEBEN cumplir con el sistema de coordenadas del sensor de Android tal como se detallan en las
APIs de Android (consulta [Recursos, 41])
DEBEN ser capaces de medir desde la caída libre hasta el doble de la gravedad (2g) o más en
cualquier vector tridimensional
DEBEN tener 8 bits de precisión o más
DEBEN tener una desviación estándar no mayor que 0.05 m/s^2
7.3.2.
Magnetómetro
Las implementaciones del dispositivo DEBEN incluir un magnetómetro de 3 ejes (es decir, una brújula). Si un
dispositivo incluye un magnetómetro de 3 ejes, debe cumplir con lo siguiente:
DEBE ser capaz de proporcionar eventos a 10 Hz o más
DEBE cumplir con el sistema de coordenadas del sensor de Android tal como se detalló en las
APIs de Android (consulta [Recursos, 41]).
DEBE ser capaz de tomar muestras de un rango de intensidades de campo adecuadas para cubrir el
campo geomagnético
DEBE tener 8 bits de precisión o más
DEBE tener una desviación estándar no mayor que 0.5 µT
7.3.3. GPS
Las implementaciones de dispositivos DEBEN incluir un receptor GPS. Si una implementación de dispositivo
incluye un receptor GPS, DEBE incluir alguna forma de técnica de "GPS asistido"
para minimizar el tiempo de enclavamiento del GPS.
7.3.4. Giroscopio
Las implementaciones de dispositivos DEBEN incluir un giroscopio (es decir, un sensor de cambio angular).
Los dispositivos NO DEBEN incluir un sensor de giroscopio, a menos que también se incluya un accelerómetro de 3 ejes.
Si una implementación de dispositivo incluye un giroscopio, debe cumplir con los siguientes requisitos:

DEBE tener compensación de temperatura
DEBE ser capaz de medir cambios de orientación de hasta 5.5 × Pi
radianes/segundo (es decir, aproximadamente 1,000 grados por segundo)
DEBE ser capaz de proporcionar eventos a 200 Hz o más. Ten en cuenta que, si bien la frecuencia del giroscopio anterior se indica como "DEBEN" para Android 4.1, se planifica que la
definición de compatibilidad para una versión futura la cambie a
"DEBEN".
Es decir, estos estándares son opcionales en Android 4.1, pero serán
obligatorios en versiones futuras. Se recomienda
muy enfáticamente a los dispositivos existentes y nuevos que ejecuten Android 4.1 que cumplan con estos requisitos en Android 4.1 para que puedan actualizarse a las próximas versiones de la plataforma.
DEBEN tener 12 bits de precisión o más.
DEBEN tener una varianza no mayor que 1e-7 rad^2 / s^2 por Hz (varianza por Hz,
o rad^2 / s).
La varianza debe variar con la tasa de muestreo, pero debe estar
limitada por este valor. En otras palabras, si mides la varianza del giroscopio
a 1 Hz de tasa de muestreo, no debe ser mayor que 1e-7 rad^2/s^2.
DEBEN tener marcas de tiempo lo más cercanas posible al momento en que ocurrió el evento de hardware.
Se debe quitar la latencia constante.
7.3.5. Barómetro
Las implementaciones del dispositivo PUEDEN incluir un barómetro (es decir, un sensor de presión del aire ambiente). Si
una implementación de dispositivo incluye un barómetro, debe cumplir con los siguientes requisitos:
DEBE ser capaz de enviar eventos a 5 Hz o más
DEBE tener una precisión adecuada para permitir estimar la altitud
DEBE tener compensación de temperatura
7.3.7. Termómetro
Las implementaciones del dispositivo PUEDEN pero NO DEBEN incluir un termómetro (es decir, un sensor de temperatura
). Si una implementación de dispositivo incluye un termómetro, debe
medir la temperatura de la CPU del dispositivo. NO DEBE MEDIR ninguna otra
temperatura. (Ten en cuenta que este tipo de sensor quedó en desuso en las APIs de Android 4.1).
7.3.7. Fotometro
Las implementaciones del dispositivo PUEDEN incluir un fotómetro (es decir, un sensor de luz ambiente).
7.3.8. Sensor de proximidad
Las implementaciones de dispositivos PUEDEN incluir un sensor de proximidad. Si una implementación de dispositivo
incluye un sensor de proximidad, DEBE medir la proximidad de un objeto en la
misma dirección que la pantalla. Es decir, el sensor de proximidad DEBE estar orientado para detectar
objetos cerca de la pantalla, ya que el objetivo principal de este tipo de sensor es detectar un
teléfono en uso por el usuario. Si una implementación de dispositivo incluye un sensor de proximidad con
cualquier otra orientación, NO SE DEBE poder acceder a través de esta API. Si una implementación de
del dispositivo tiene un sensor de proximidad, DEBE tener 1 bit de precisión o más.
7.4. Conectividad de datos
7.4.1. Telephony
El término “Telephony” tal como se usa en las APIs de Android 4.1 y este documento se refiere específicamente al
hardware relacionado con realizar llamadas de voz y enviar mensajes SMS a través de una red GSM o
CDMA. Si bien estas llamadas de voz pueden o no ser conmutadas por paquetes,
para los fines de Android 4.1 se consideran independientes de cualquier conectividad de datos que
se pueda implementar con la misma red. En otras palabras, la funcionalidad y las APIs de "telephony"
de Android se refieren específicamente a las llamadas de voz y a 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 ningún subelemento, independientemente de si usan una red móvil para la conectividad de datos.

Android 4.1 SE PUEDE usar en dispositivos que no incluyan hardware de telefonía. Es decir,
Android 4.1 es compatible con dispositivos que no son teléfonos. Sin embargo, si una implementación
de dispositivo incluye telefonía GSM o CDMA, debe implementar la compatibilidad completa
con la API para esa tecnología. Las implementaciones de dispositivos que no incluyan 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 4.1 DEBEN incluir compatibilidad con uno o más tipos
de 802.11 (b/g/a/n, etc.) Si una implementación de dispositivo incluye compatibilidad con 802.11,
DEBE implementar la API de Android correspondiente.

Las implementaciones de dispositivos DEBEN implementar la API de multicast como se describe en la documentación del SDK
[Recursos, 62]. Las implementaciones de dispositivos que sí incluyen compatibilidad con Wi-Fi
DEBEN ser compatibles con DNS multicast (mDNS). Las implementaciones de dispositivos NO DEBEN filtrar los paquetes
de mDNS (224.0.0.251) en ningún momento de operación, incluso cuando la pantalla no esté en un estado
activo.
7.4.2.1. Wi-Fi Direct
Las implementaciones de dispositivos DEBEN incluir compatibilidad con Wi-Fi Direct (Wi-Fi punto a punto). 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, 68]. Si
una implementación de dispositivo incluye compatibilidad con Wi-Fi Direct, entonces debe cumplir con lo siguiente:
DEBE ser compatible con el funcionamiento normal de Wi-Fi
DEBE ser compatible con el funcionamiento simultáneo de Wi-Fi y Wi-Fi Direct
7.4.3. Bluetooth
Las implementaciones de dispositivos DEBEN incluir un transmisor-receptor Bluetooth. Las implementaciones de dispositivos que incluyan un transmisor-receptor Bluetooth DEBEN habilitar la API de Bluetooth basada en RFCOMM-
, como se describe en la documentación del SDK [Recursos, 42].
Las implementaciones del dispositivo DEBEN implementar perfiles Bluetooth relevantes, como A2DP,
AVRCP, OBEX, etc., según corresponda para el dispositivo.

El conjunto de pruebas de compatibilidad incluye casos que cubren el funcionamiento básico de la API de Bluetooth
RFCOMM de Android. Sin embargo, como Bluetooth es un protocolo de comunicación
entre dispositivos, no se puede probar por completo con pruebas de unidades que se ejecutan en un solo dispositivo.
En consecuencia, las implementaciones de dispositivos TAMBIÉN DEBEN superar el procedimiento de prueba de Bluetooth
guiado por humanos que se describe en el Apéndice A.
7.4.4. Comunicación de campo cercano
Las implementaciones de dispositivos DEBEN incluir un transmisor-receptor y hardware relacionado para la
Comunicación de campo cercano (NFC). Si una implementación de dispositivo incluye hardware NFC
, entonces debe cumplir con lo siguiente:
FAN informar la función android.hardware.nfc desde el método
android.content.pm.PackageManager.hasSystemFeature().
[Recursos, 37]
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 un lector/escritor de NFC Forum (según se define en la especificación técnica NFCForum-TS-DigitalProtocol-1.0)
a través de los siguientes estándares de NFC:
NfcA (ISO14443-3A)
NfcB (ISO14443-3B)
NfcF (JIS 6319-4)
IsoDep (ISO 14443-4)
NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)
DEBEN ser capaces 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 NFC que se mencionan a continuación se indican como
"DEBEN" para Android 4.1, la Definición de Compatibilidad para una versión futura es
planificar cambiar estos a "DEBEN". Es decir, estos estándares son opcionales en
Android 4.1, pero serán obligatorios en versiones futuras. Se recomienda muy enfáticamente a los dispositivos existentes y nuevos
que ejecuten Android 4.1 que cumplan con estos
requisitos en Android 4.1 para que puedan actualizarse a las próximas versiones de la
plataforma.
NfcV (ISO 15693)
DEBE ser capaz de transmitir y recibir datos a través de los siguientes estándares y protocolos de
igual a igual:
ISO 18092
LLCP 1.0 (definido por el NFC Forum)
SDP 1.0 (definido por el NFC Forum)
Protocolo de inserción NDEF [Recursos, 43]
SNEP 1.0 (definido por el NFC Forum)
DEBE incluir compatibilidad con Android Beam [Recursos, 65]:
DEBE implementar el servidor predeterminado de SNEP. Los mensajes NDEF válidos
que recibe el servidor SNEP predeterminado DEBEN enviarse a las aplicaciones
mediante el intent android.nfc.ACTION_NDEF_DISCOVERED. Inhabilitar
Android Beam en la configuración NO DEBE inhabilitar el envío de mensajes NDEF
entrantes.
Las implementaciones de dispositivos DEBEN respetar el intent
android.settings.NFCSHARING_SETTINGS para mostrar la configuración de uso compartido de NFC

[Recursos, 67].
DEBEN implementar el servidor NPP. Los mensajes que recibe el servidor NPP
DEBEN procesarse de la misma manera que el servidor predeterminado de SNEP.
DEBEN implementar un cliente de SNEP y tratar de enviar NDEF P2P de salida
al servidor predeterminado de SNEP cuando Android Beam esté habilitado. Si no se encuentra un servidor
SNEP predeterminado, el cliente DEBE intentar enviar a un servidor
NPP.
DEBE permitir que las actividades en primer plano establezcan el mensaje NDEF P2P de salida
con android.nfc.NfcAdapter.setNdefPushMessage, y
android.nfc.NfcAdapter.setNdefPushMessageCal de vuelta, y
android.nfc.NfcAdapter.enableForegroundNdefPush.
DEBE usar un gesto o una confirmación en pantalla, como "Tocar para
Beam", antes de enviar mensajes NDEF P2P de salida.
DEBE habilitar Android Beam de forma predeterminada
DEBE admitir la entrega de conexión NFC a Bluetooth cuando el dispositivo
admite el perfil de empuje 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 de
"Connection Handover version 1.2" [Resources, 60] y "Bluetooth Secure
Simple Pairing Using NFC version 1.0" [Resources, 61] del
NFC Forum. Una implementación SHOULD usa solicitudes GET de SNEP
para intercambiar la solicitud de transferencia o seleccionar registros a través de NFC, y
DEBE usar el perfil de empuje de objetos Bluetooth para la transferencia real de datos Bluetooth
.
DEBE buscar todas las tecnologías compatibles mientras está en modo de detección de NFC.
DEBE estar en modo de detección de NFC mientras el dispositivo está activo con la pantalla
activa y la pantalla de bloqueo desbloqueada.
(Ten en cuenta que los vínculos disponibles para el público no están disponibles para las especificaciones de JIS, ISO y NFC Forum
mencionadas anteriormente).
Además, las implementaciones de dispositivos PUEDEN incluir compatibilidad con lectores/escribientes para las
siguientes tecnologías de MIFARE.
MIFARE Classic (NXP MF1S503x [Resources, 44], MF1S703x [Resources, 44])
MIFARE Ultralight (NXP MF0ICU1 [Resources, 46], MF0ICU2 [Resources, 46])
NDEF en MIFARE Classic (NXP AN1 30511 [Resources, 48], AN130411
[Resources, 49])
Ten en cuenta que Android 4.1 incluye APIs para estos tipos de MIFARE. Si una implementación
de dispositivo es compatible con MIFARE en el rol de lector/escritor, debe cumplir con lo siguiente:
FAN implementar las APIs de Android correspondientes tal como se documenta en el
SDK de Android
FAN informar la función com.nxp.mifare desde el método
android.content.pm.PackageManager.hasSystemFeature().
[Resources, 37] 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 DEBEN declarar la función
android.hardware.nfc desde el método
android.content.pm.PackageManager.hasSystemFeature() [Resources, 37],
y DEBEN implementar la API de NFC de Android 4.1 como una no operación.
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 mínima de red
Las implementaciones de dispositivos DEBEN incluir compatibilidad con una o más formas de red
de datos. Específicamente, las implementaciones de dispositivos DEBEN incluir compatibilidad con al menos un
estándar de datos capaz de 200 Kbit/s o más. Entre los ejemplos de tecnologías que
cumplen con este requisito, se incluyen EDGE, HSPA, EV-DO, 802.11g, Ethernet, etc.
Las implementaciones de dispositivos en las que un estándar de red física (como Ethernet) es
la conexión de datos principal DEBEN también incluir compatibilidad con al menos un estándar de datos inalámbricos común, como 802.11 (Wi-Fi).

Los dispositivos PUEDEN implementar más de un tipo de conectividad de datos.

7.5. Cámaras
Las implementaciones del dispositivo DEBEN incluir una cámara posterior y PUEDEN incluir una
cámara frontal. Una cámara posterior es una cámara ubicada en el lado del
dispositivo opuesto a la pantalla; es decir, captura imágenes de escenas en el extremo más alejado del dispositivo, como
una cámara tradicional. Una cámara frontal es una cámara ubicada en el mismo lado de
el dispositivo que la pantalla; es decir, una cámara típica y se usa para capturar imágenes del usuario, como en el caso de
video conferencias y aplicaciones similares.
7.5.1. Cámara posterior
Las implementaciones del dispositivo DEBEN incluir una cámara posterior. Si la implementación de un dispositivo
incluye una cámara posterior, debe cumplir con los siguientes requisitos:
DEBE tener una resolución de al menos 2 megapíxeles
DEBE tener el enfoque automático de hardware o el enfoque automático de software implementado
en el controlador de la cámara (transparente para el software de aplicación)
PUEDE tener hardware de enfoque fijo o EDOF (profundidad de campo extendida)
PUEDE incluir un flash. Si la cámara incluye un flash, la lámpara del flash NO DEBE estar
encendida mientras se haya
registrado una instancia posterior de android.hardware.Camera.PreviewCal en una superficie de vista previa de la cámara, a menos que la aplicación haya
habilitado de forma explícita el flash habilitando los atributos FLASH_MODE_AUTO o FLASH_MODE_ON
de un objeto Camera.Parameters. Ten en cuenta que esta restricción no se aplica a la aplicación de cámara del sistema integrada en el
dispositivo, sino solo a las aplicaciones de terceros
que usan Camera.PreviewCallback.
7.5.2. Cámara frontal
Las implementaciones del dispositivo PUEDEN incluir una cámara frontal. Si una implementación de dispositivo
incluye una cámara frontal, debe cumplir con los siguientes requisitos:
DEBE tener una resolución de al menos VGA (es decir, 640 x 480 píxeles)
NO DEBE usar una cámara frontal como la predeterminada para la API de Camera. Es decir,
la API de la cámara en Android 4.1 tiene compatibilidad específica con cámaras frontales, y las implementaciones de dispositivos NO DEBEN configurar la API para tratar 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 cámaras
posteriores como se describe en el artículo 7.5.1.
DEBEN ser horizontales y reflejar (es decir, duplicar) la transmisión que muestra una app en un
CameraPreview, como se indica a continuación:
Si la implementación del dispositivo es capaz de ser rotada por el usuario (como
automáticamente a través de un accelerometer o manualmente a través de la entrada del usuario), la vista previa
de la cámara DEBE ser duplicada horizontalmente y 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 rotara a través de una llamada al método
android.hardware.Camera.setDisplayOrientation() [Resources, 50]
, la vista previa de la cámara DEBE ser duplicada horizontalmente y en relación con la orientación
especificada por la aplicación.
De lo contrario, la vista previa DEBE ser duplicada a lo largo del eje horizontal
predeterminado del dispositivo.

DEBE reflejar la imagen que muestra la vista posterior de la misma manera que el flujo de imágenes de la vista previa de la
cámara. (Si la implementación del dispositivo no admite
postview, este requisito obviamente no se aplica).
NO DEBEN reflejar la imagen o las transmisiones de video capturadas finalmente que se muestran en las funciones de recuperación de la aplicación o se confirman en el almacenamiento de medios
7.5.3.
Comportamiento de la API de la cámara
Las implementaciones de dispositivos DEBEN implementar los siguientes comportamientos para las APIs relacionadas con la cámara, para las cámaras frontales y posteriores:
1.
  Si una aplicación nunca llamó a
android.hardware.Camera.Parameters.setPreviewFormat(int), entonces el
dispositivo DEBE usar android.hardware.PixelFormat.YCbCr_420_SP para los datos
de vista previa proporcionados a las funciones de llamada de aplicación.
2.  Si una aplicación registra una instancia de android.hardware.Camera.PreviewCallback
y el sistema llama al método onPreviewFrame() cuando el formato de preview
es YCbCr_420_SP, los datos en el byte[] que se pasan a onPreviewFrame()
deben estar en el formato de codificación NV21. Es decir, NV21 DEBE ser la opción predeterminada.
3.  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 para las
cameras frontales y posteriores. (El decodificador 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).
Las implementaciones de dispositivos DEBEN implementar la API de cámara completa incluida en la documentación del SDK de Android
4.1 [Recursos, 51]), independientemente de si el dispositivo incluye autoenfoque de hardware o otras funciones.
Por ejemplo, las cámaras que no tienen enfoque automático
DEBEN igualmente llamar a cualquier instancia registrada de android.hardware.Camera.AutoFocusCallback
(aunque esto no tenga relevancia 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 API de cámaras posteriores deben seguir siendo "falsas" como
se describe.
Las implementaciones del dispositivo 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 de
debe comportarse como se documenta. Por el contrario, las implementaciones de dispositivos NO DEBEN
respetar ni reconocer constantes de cadenas que se pasen al método
android.hardware.Camera.setParameters() que no sean las documentadas como
constantes en el android.hardware.Camera.Parameters. Es decir, las implementaciones de
dispositivos DEBEN admitir todos los parámetros estándares de la cámara si el hardware
lo permite, y NO DEBEN admitir tipos de parámetros personalizados de la cámara.
Las implementaciones del dispositivo DEBEN transmitir el intent Camera.ACTION_NEW_PICTURE
cada vez que la cámara tome una foto nueva y la entrada de la foto se haya
agregado al almacenamiento de media.
Las implementaciones de dispositivos DEBEN transmitir el intent Camera.ACTION_NEW_VIDEO
cada vez que la cámara graba un video nuevo y la entrada de la foto se ha
agregado al almacenamiento multimedia.
7.5.4. Orientación de la cámara
Si están presentes, las cámaras frontal y posterior SE DEBEN orientar 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 la orientación horizontal, las cámaras DEBEN capturar imágenes en la orientación
horizontal. Esto se aplica independientemente de la orientación natural del dispositivo; es decir, se aplica a dispositivos con orientación horizontal primaria y también a dispositivos con orientación vertical primaria.

7.6. Memoria y almacenamiento
7.6.1. Memoria y almacenamiento mínimos
Las implementaciones de dispositivos DEBEN tener al menos 340 MB de memoria disponible para el kernel
y el espacio de usuario. Los 340 MB DEBEN ser además de cualquier memoria dedicada a
componentes de hardware como radio, video, etcétera que no estén bajo el control del
kernel.
Las implementaciones de dispositivos DEBEN tener al menos 350 MB de almacenamiento no volátil disponible
para los datos privados de la aplicación. Es decir, la partición /data DEBE ser de al menos 350 MB.
Las APIs de Android incluyen un Administrador de descargas que las aplicaciones pueden usar para descargar
archivos de datos [Recursos, 56]. La implementación del dispositivo del Administrador de descargas
DEBE ser capaz de descargar archivos individuales de al menos 100 MB de tamaño a la ubicación predeterminada de la "caché".

7.6.2. Almacenamiento compartido de aplicaciones
Las implementaciones de dispositivos DEBEN ofrecer almacenamiento compartido para aplicaciones. El almacenamiento
compartido proporcionado DEBE ser de al menos 1 GB de tamaño.
Las implementaciones del dispositivo DEBEN configurarse con almacenamiento compartido activado de forma predeterminada,
"listo para usar". 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 del dispositivo 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 PUEDE escribir en el almacenamiento compartido.

Las implementaciones de dispositivos PUEDEN tener hardware para almacenamiento extraíble accesible por el usuario,
como una tarjeta Secure Digital. Como alternativa, las implementaciones del dispositivo PUEDEN al ocate
almacenamiento interno (no extraíble) como almacenamiento compartido para apps.

Independientemente del tipo 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 en masa USB (UMS) o el protocolo de transferencia multimedia (MTP).
Las implementaciones de dispositivos PUEDEN usar el almacenamiento en masa USB, pero DEBEN usar el protocolo de transferencia
multimedia. Si la implementación del dispositivo admite el protocolo de transferencia de contenido multimedia,
la implementación del dispositivo DEBE ser compatible con el host MTP de referencia de Android, Transferencia de archivos de Android [Recursos, 57].
La implementación del dispositivo DEBE informar una clase de dispositivo USB de 0x00.
La implementación del dispositivo DEBE informar un nombre de interfaz USB de "MTP".

Si la implementación del dispositivo no tiene puertos USB, DEBE proporcionar a una computadora host
acceso al contenido del almacenamiento compartido por otros medios, como un sistema de archivos
de red.
Es útil considerar dos ejemplos comunes. Si una implementación de dispositivo incluye
una ranura para tarjeta SD para cumplir con el requisito de almacenamiento compartido, SE DEBE incluir una tarjeta SD con formato FAT
de 1 GB o más con el dispositivo tal como se vende a los usuarios y SE DEBE
activar de forma predeterminada. Como alternativa, si una implementación de dispositivo usa almacenamiento
interno fijo para satisfacer este requisito, ese almacenamiento DEBE ser de 1 GB de tamaño o más y
montado en /sdcard (o /sdcard DEBE ser un vínculo simbólico a la ubicación física si
está montado en otro lugar).
Las implementaciones de dispositivos que incluyen múltiples rutas de almacenamiento compartidos (como un
ranura para tarjeta SD y almacenamiento interno compartido) DEBEN modificar las aplicaciones principales como
el escáner multimedia y ContentProvider para admitir de forma transparente los archivos ubicados en ambas
ubicaciones.
7.7. Las implementaciones de dispositivos USB
DEBEN incluir un puerto cliente USB y DEBEN incluir un puerto host
USB.
Si una implementación de dispositivo incluye un puerto cliente USB,
el puerto DEBE ser conectable a un host USB con un puerto USB-A estándar
el puerto DEBERIA usar el factor de forma micro USB en el lado del dispositivo. Se recomienda muy enfáticamente a los dispositivos existentes y nuevos que ejecuten Android 4.1 que cumplan
estos requisitos en Android 4.1 para que puedan actualizarse a las futuras versiones de la
plataforma
. El puerto DEBE estar centrado en el medio de un borde.
Las implementaciones de dispositivos
DEBEN ubicar el puerto 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), de modo que la pantalla se dibuje correctamente cuando el dispositivo esté orientado con el puerto
en la parte inferior. Se recomienda muy fuertemente
a los dispositivos existentes y nuevos que ejecuten Android 4.1 que cumplan con estos requisitos en Android 4.1 para que puedan actualizarse a futuras versiones de la plataforma.
Si el dispositivo tiene otros puertos (como un puerto de carga no USB), DEBE estar
en el mismo extremo que el puerto micro-USB.
DEBE implementar la API y la especificación de Android Open Accessory como se documenta en la documentación del SDK de Android, y DEBE declarar la compatibilidad con la función de hardware android.hardware.usb.accessory [Resources, 52].
DEBE implementar la clase de audio USB como se documenta en la documentación del SDK de Android
[Resources, 66].
DEBE implementar la compatibilidad con la especificación de carga de la batería USB
[Resources, 64]. Se recomienda muy
fuertemente a los dispositivos existentes y nuevos que ejecuten Android 4.1 que cumplan con estos requisitos en Android 4.1 para que puedan actualizarse a futuras versiones de la plataforma.
Si una implementación de dispositivo incluye un puerto host USB,
PUEDE usar un factor de forma de puerto no estándar, pero si es así, DEBE enviarse con un cable o
cables que adapten el puerto a USB-A estándar.
DEBE implementar la API de host USB de Android como se documenta en el SDK de Android, y DEBE declarar la compatibilidad con la función de hardware android.hardware.usb.host [Resources, 53].
Las implementaciones de dispositivos DEBEN implementar el puente de depuración de Android.

Si una implementación
de dispositivos omite un puerto cliente USB, DEBE implementar el puente de depuración de Android
a través de una red de área local (como Ethernet o 802.11)

8. Compatibilidad de rendimiento
Las implementaciones de dispositivos DEBEN cumplir con las métricas de rendimiento claves de un dispositivo compatible con Android 4.1
definidas en la siguiente tabla:
Métrica
Umbral de rendimiento
Comentarios
Las siguientes aplicaciones
deben inicio dentro del tiempo especificado.

El tiempo de inicio se mide como el
tiempo total para completar la carga del
браузер: menos de
actividad predeterminada para la aplicación,
aplicación
1300 ms
incluido el tiempo que tarda en iniciar el
tiempo de inicio
contactos: menos de
proceso de Linux, carga el paquete de Android
700 ms
en la VM de Dalvik, y cal
configuración: menos de
onCreate.
700 ms
Cuando se iniciaron varias aplicaciones
, el
inicio de una aplicación ya
simultánea
en ejecución después de que

Aplicaciones
se iniciaron debe
tomar menos que el tiempo de inicio
original.
9. Compatibilidad con el modelo de seguridad
Las implementaciones de dispositivos DEBEN implementar un modelo de seguridad consistente con el modelo de seguridad de la plataforma
de Android, tal como se define en el documento de referencia de seguridad y permisos en
las APIs [Recursos, 54] en la documentación para desarrolladores de Android. Las
implementaciones de dispositivos DEBEN admitir la instalación de aplicaciones autofirmadas sin
requerir ningún permiso o certificado adicional de terceros o autoridades.
Específicamente, los dispositivos compatibles DEBEN admitir los mecanismos de seguridad que se describen en
las siguientes subsecciones.
9.1. Permisos
Las implementaciones del dispositivo DEBEN admitir el modelo de permisos de Android tal como se define en
la documentación para desarrolladores de Android [Recursos, 54]. Específicamente, las implementaciones
DEBEN aplicar cada permiso definido como se describe en la documentación del SDK. Ningún
permiso se puede omitir, alterar o ignorar. Las implementaciones PUEDEN agregar permisos
adicionales, siempre y cuando las cadenas de ID de permiso nuevas no estén en el espacio de nombres android.*
.
9.2. UID y aislamiento de 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 único de estilo Unix y en un proceso separado.
Las implementaciones de dispositivos DEBEN admitir la ejecución de varias aplicaciones como el mismo ID de usuario de
Linux, siempre y cuando las aplicaciones estén firmadas y completadas de forma adecuada, como
se define en la referencia de Seguridad y Permisos [Recursos, 54].

9.3. Permisos del sistema de archivos
Las implementaciones de dispositivos DEBEN admitir el modelo de permisos de acceso a archivos de Android tal como se define en la referencia de Seguridad y Permisos [Recursos, 54].

9.4. Entornos de ejecución alternativos
Las implementaciones de dispositivos PUEDEN incluir entornos de ejecución que ejecutan aplicaciones
con algún otro software o tecnología que no sea la máquina virtual 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 instaladas de Android, como se describe
en esta sección.
Los entorno de ejecución alternativos DEBEN ser aplicaciones de Android y cumplir con el
modelo de seguridad estándar de Android, como se describe en otra parte de la Sección 9.
Los tiempos de ejecución alternativos NO DEBEN tener acceso a recursos protegidos por permisos
que no se soliciten en el archivo AndroidManifest.xml del tiempo de ejecución a través del mecanismo <uses-
permission>.

Los tiempos de ejecución alternativos NO DEBEN permitir que las aplicaciones usen funciones protegidas
por permisos de Android restringidos a aplicaciones del sistema.
Los entornos de ejecución alternativos DEBEN cumplir con el modelo de zona de pruebas de Android. Específicamente:
Los entorno de ejecución alternativos DEBEN instalar  apps a través de PackageManager en
zonas de pruebas de Android separadas (es decir, IDs de usuario de Linux, etc.)
Los entorno de ejecución alternativos PUEDEN proporcionar una sola zona de pruebas de Android compartida por todas
las aplicaciones que usan el entorno de ejecución alternativo
Los entorno de ejecución alternativos y las aplicaciones instaladas que usan un entorno de ejecución alternativo NO DEBEN volver a usar la zona de pruebas de ninguna otra app instalada en el dispositivo, excepto a través de
los mecanismos estándares de Android de ID de usuario compartido y certificado de firma
Los entorno de ejecución alternativos NO DEBEN iniciar con, otorgar ni recibir acceso a las
zonas de pruebas correspondientes a otras aplicaciones de Android
Los entorno de ejecución alternativos NO DEBEN iniciar con, otorgar ni recibir a otras
aplicaciones ningún privilegio del superusuario (root), ni de ningún otro ID de usuario.

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 clave que se usa para firmar otras aplicaciones
incluidas con la implementación del dispositivo.
Cuando se instalan aplicaciones, los tiempos de ejecución alternativos DEBEN obtener el consentimiento del usuario para los permisos de
Android que usa la aplicación. Es decir, si una aplicación necesita hacer
uso de un recurso del dispositivo para el que hay un permiso de Android correspondiente (como
la cámara, el GPS, etc.), 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 funciones 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 use ese entorno.

10. Pruebas de compatibilidad de software
Las implementaciones de dispositivos DEBEN superar las pruebas descritas en esta sección.
Sin embargo, ten en cuenta que ningún paquete de prueba de software es completo ni exhaustivo. Por este motivo,se recomienda muy enfáticamente a los
implementadores de dispositivos que realicen la cantidad mínima posible de
cambios en la implementación referenciada y preferida de Android 4.1
disponible en el Proyecto de Código Abierto de Android. Esto  minimiza el riesgo de
introducir errores que creen incompatibilidades que requieren rehacer y posibles actualizaciones
del dispositivo.
10.1. Conjunto de pruebas de compatibilidad
Las implementaciones del dispositivo DEBEN aprobar el Conjunto de pruebas de compatibilidad (CTS) de Android
[Recursos, 2] 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 fuente abierto de Android tanto como sea posible, y
DEBEN garantizar la compatibilidad en casos de ambigüedad en CTS y para cualquier
reimplementación de partes del código fuente de referencia.
El CTS está diseñado para ejecutarse en un dispositivo real. Como cualquier software, es posible
que el CTS también tenga errores. El CTS tendrá  una versión independiente de esta Definición
de Compatibilidad, y es posible que se lancen varias revisiones del CTS para Android 4.1. Las implementaciones de
dispositivos DEBEN superar la versión más reciente de CTS disponible en el momento en que se completa el software
del dispositivo.
10.2. Verificador de CTS
Las implementaciones de dispositivos DEBEN ejecutar correctamente todos los casos aplicables en el verificador de CTS
. El verificador del CTS se incluye con el conjunto de pruebas de compatibilidad y está diseñado para que lo ejecute un operador humano para probar la funcionalidad que no se puede probar con 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 algún hardware que
es opcional. Las implementaciones de dispositivos DEBEN aprobar todas las pruebas de hardware que
posean. Por ejemplo, si un dispositivo posee un acelerómetro, DEBE
ejecutar correctamente el caso de prueba del acelerómetro en el verificador de CTS. SE PUEDEN OMITIR los casos de prueba para las funciones que se indican
como opcionales en este Documento de Definición de Compatibilidad.
Cada dispositivo y cada compilación DEBEN ejecutar correctamente el verificador CTS, como se mencionó anteriormente.
Sin embargo, como muchas compilaciones son muy similares, no se espera que los implementadores de dispositivos
ejecuten de forma explícita el verificador CTS en compilaciones que solo diffieran de formas triviales. Específicamente, las implementaciones de dispositivos que diffieran de una implementación que haya aprobado el verificador de CTS
solo por el conjunto de configuraciones regionales, marcas, etc., PUEDEN omitir la prueba del verificador de CTS

.

10.3. Aplicaciones de referencia
Los implementadores de dispositivos DEBEN probar la compatibilidad de la implementación con las siguientes aplicaciones de código abierto:
Las aplicaciones "Apps for Android" [Resources, 55]
Replica Island (disponible en Android Market)
Cada app anterior DEBE inicio y comportarse correctamente en la implementación, para que la
implementación se considere compatible.

11. Software actualizable
Las implementaciones de dispositivos DEBEN incluir un mecanismo para reemplazar la totalidad del software del
sistema. El mecanismo no necesita realizar actualizaciones "en vivo", es decir, es POSIBLE que se requiera un
reinicio del dispositivo.
Se puede usar cualquier método, siempre que pueda reemplazar la totalidad del software
preinstalado en el dispositivo. Por ejemplo, cualquiera de los siguientes enfoques cumplirá con
este requisito:
Descargas inalámbricas (OTA) con actualización sin conexión a través de un reinicio
Actualizaciones"con conexión" por USB desde una PC host
Actualizaciones"sin conexión" a través de un reinicio y actualización desde un archivo en almacenamiento extraíble
El mecanismo de actualización que se use DEBE admitir actualizaciones sin borrar los datos del usuario. Es decir,
el mecanismo de actualización DEBE preservar los datos privados y los datos compartidos
de la aplicación. Ten en cuenta que el software upstream de Android incluye un mecanismo de actualización
que cumple con este requisito.
Si se encuentra un error en la implementación de un dispositivo después de su lanzamiento, pero dentro de su
vida útil razonable que se determina en consulta con el equipo de compatibilidad de
Android para afectar la compatibilidad de aplicaciones de terceros, el
implementador del dispositivo DEBE corregir el error a través de una actualización de software disponible que se pueda
aplicar según el mecanismo que acabamos de describir.
12. Comunícate con nosotros
Puedes comunicarte con los autores del documento a compatibility@android.com para obtener aclaraciones
y para mencionar cualquier problema que consideres que el documento no aborda.

Apéndice A: Procedimiento de prueba de Bluetooth
El paquete de pruebas de compatibilidad incluye casos que cubren el funcionamiento básico de la API de Bluetooth
RFCOMM de Android. Sin embargo, como Bluetooth es un protocolo de comunicación
entre dispositivos, no se puede probar por completo con pruebas de unidades que se ejecutan en un solo dispositivo.
Por lo tanto, las implementaciones de dispositivos TAMBIÉN DEBEN superar el procedimiento de prueba de Bluetooth
operado por humanos que se describe a continuación.
El procedimiento de prueba se basa en la app de muestra BluetoothChat incluida en el árbol del proyecto de código abierto de
Android. El procedimiento requiere dos dispositivos:
una implementación de dispositivo candidata que ejecute la compilación de software que se probará
una implementación de dispositivo separada que ya se sabe que es compatible, y de un
modelo de la implementación de dispositivo que se está probando, es decir, una implementación de dispositivo
"conocida como buena"
En el procedimiento de prueba que se presenta a continuación, se hace referencia a estos dispositivos como los dispositivos "candidato" y "conocidos
como buenos", respectivamente.
Configuración y instalación
1.  Compila BluetoothChat.apk a través de "make samples" desde un árbol de código fuente de Android
2.  Instala  BluetoothChat.apk en el dispositivo en buen estado.
3.  Instala  BluetoothChat.apk en el dispositivo candidato.
Prueba el control de Bluetooth por apps
1.  Inicia BluetoothChat en el dispositivo candidato, mientras Bluetooth está inhabilitado
2.  Verifica que el dispositivo candidato active Bluetooth o le solicite al usuario
con un diálogo que active Bluetooth
Prueba la vinculación y la comunicación
1.  Inicia la app de Chat por Bluetooth en ambos dispositivos
2.  Haz que el dispositivo en buen estado sea detectable desde dentro de BluetoothChat (con el
menú).
3.  En el dispositivo candidato, busca dispositivos Bluetooth desde BluetoothChat
(con el menú) y vincula con el dispositivo conocido como bueno
4.  Envía 10 o más mensajes desde cada dispositivo y verifica que el otro dispositivo
los reciba correctamente
5.  Cierra la app BluetoothChat en ambos dispositivos presionando Inicio
6.  Desvincula cada dispositivo del otro con la app Configuración del dispositivo.
Prueba la vinculación y la comunicación en el sentido
inverso
1.  Inicia la app de Chat por Bluetooth en ambos dispositivos.
2.  Haz que el dispositivo candidato sea detectable desde dentro de BluetoothChat (con el menú
).
3.  En el dispositivo conocido como bueno, busca dispositivos Bluetooth desde BluetoothChat
(con el menú) y vincula el dispositivo candidato.
4.  Envía 10 o más mensajes desde cada dispositivo y verifica que el otro dispositivo
los reciba correctamente.
5.  Para cerrar la app de Chat por Bluetooth en ambos dispositivos, presiona Atrás repetidamente para
llegar al Selector.
Prueba los relanzamientos
1.  Vuelve a iniciar la app de Chat por Bluetooth en ambos dispositivos.
2.  Envía 10 o más mensajes desde cada dispositivo y verifica que el otro dispositivo
los reciba correctamente.
Nota: Las pruebas anteriores tienen algunos casos que terminan una sección de prueba con la función Inicio y
algunos con Atrás. Estas pruebas no son redundantes ni opcionales: el objetivo es
verificar que la API y la pila de Bluetooth funcionen correctamente tanto cuando las actividades se
cierran de forma explícita (a través de que el usuario presione Atrás, que es la acción de finalizar), como cuando se envían de forma implícita
a segundo plano (a través de que el usuario presione Inicio). Cada secuencia de prueba SE DEBE realizar
como se describe.