Definición de compatibilidad con Android 2.1

Copyright © 2010, Google Inc. Todos los derechos reservados.
compatibilidad@android.com

1. Introducción

Este documento enumera los requisitos que se deben cumplir para que los teléfonos móviles sean compatibles con Android 2.1.

El uso de "debe", "no debe", "obligatorio", "deberá", "no deberá", "debería", "no debería", "recomendado", "puede" y "opcional" se ajusta al estándar del IETF. definido en RFC2119 [ Recursos, 1 ].

Tal como se utiliza en este documento, un "implementador de dispositivos" o "implementador" es una persona u organización que desarrolla una solución de hardware/software que ejecuta Android 2.1. Una "implementación de dispositivo" o "implementación" es la solución de hardware/software así desarrollada.

Para ser considerado compatible con Android 2.1, las implementaciones del dispositivo:

  • DEBE cumplir con los requisitos presentados en esta Definición de compatibilidad, incluido cualquier documento incorporado mediante referencia.
  • DEBE aprobar la versión más reciente del conjunto de pruebas de compatibilidad de Android (CTS) disponible en el momento en que se completa la implementación del software del dispositivo. (El CTS está disponible como parte del Proyecto de código abierto de Android [ Recursos, 2 ]). El CTS prueba muchos, pero no todos, los componentes descritos en este documento.

Cuando esta definición o el CTS no dice nada, es ambiguo o está incompleto, es responsabilidad del implementador del dispositivo garantizar la compatibilidad con las implementaciones existentes. Por esta razón, el Proyecto de código abierto de Android [ Recursos, 3 ] es la implementación de referencia y preferida de Android. Se recomienda encarecidamente a los implementadores de dispositivos que basen sus implementaciones en el código fuente "ascendente" disponible en el Proyecto de código abierto de Android. Si bien hipotéticamente algunos componentes pueden reemplazarse con implementaciones alternativas, se desaconseja encarecidamente esta práctica, ya que pasar las pruebas CTS será sustancialmente más difícil. Es responsabilidad del implementador garantizar la compatibilidad total del comportamiento con la implementación estándar de Android, incluido y más allá del Compatibility Test Suite. Finalmente, tenga en cuenta que este documento prohíbe explícitamente ciertas sustituciones y modificaciones de componentes.

2. Recursos
  • Niveles de requisitos IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  • Descripción general del programa de compatibilidad de Android: http://source.android.com/compatibility/index.html
  • Proyecto de código abierto de Android: http: //source.android.com/
  • Definiciones y documentación de API: http://developer.android.com/reference/packages.html
  • Referencia de permisos de Android: http://developer.android.com/reference/android/Manifest.permission. html
  • android.os.Referencia de Build: http://developer.android.com/reference/android/os/Build.html
  • Cadenas de versiones permitidas de Android 2.1: http://source.android.com/docs/compatibility/2.1/versions .html
  • clase android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  • HTML5: http://www.whatwg.org/specs/web-apps/current-work/
  • especificación de máquina virtual Dalvik
    •
  • /multipágina
    • : disponible en el código fuente de Android, en dalvik/docs
  • AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  • Notificaciones: http://developer.android.com /guide/topics/ui/notifiers/notifications.html
  • Recursos de la aplicación: http://code.google.com/android/reference/available-resources.html
  • Guía de estilo de los iconos de la barra de estado: http://developer.android.com/ guía/practices/ui_guideline /icon_design.html#statusbarstructure
  • Administrador de búsqueda: http://developer.android.com/reference/android/app/SearchManager.html
  • Brindis: http://developer.android.com/reference/android/widget /Toast.html
  • Fondos de pantalla en vivo: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  • Aplicaciones para Android: http://code.google.com/p/apps-for-android
  • Referencia documentación de la herramienta (para adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  • Descripción del archivo apk de Android: http://developer.android.com/guide/topics/fundamentals .html
  • Archivos de manifiesto: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  • Herramienta de prueba de mono: https://developer.android.com/studio/test/other-testing-tools/ mono
  • que admite múltiples pantallas: http://developer.android.com/guide/practices/screens_support.html
  • android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration. html
  • android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  • android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera. html
  • Espacio de coordenadas del sensor: http://developer.android.com/reference/android/hardware/SensorEvent.html
  • Referencia de permisos y seguridad de Android: http://developer.android.com/guide/topics/security/security.html
  • Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

    • Muchos de estos recursos se derivan directa o indirectamente del SDK de Android 2.1 y serán funcionalmente idénticos a la información contenida en la documentación de ese SDK. . En cualquier caso en el que esta Definición de compatibilidad o el Conjunto de pruebas de compatibilidad no estén de acuerdo con 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 parte de esta Definición de compatibilidad.

    3. Software

    La plataforma Android incluye un conjunto de API administradas, un conjunto de API nativas y un conjunto de API denominadas "blandas", como el sistema Intent y las API de aplicaciones web. Esta sección detalla las API físicas y blandas que son parte integral de la compatibilidad, así como otros comportamientos técnicos y de interfaz de usuario relevantes. Las implementaciones de dispositivos DEBEN cumplir con todos los requisitos de esta sección.

    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 Android expuestas a aplicaciones que se ejecutan en el entorno de VM administrado. Las implementaciones de dispositivos DEBEN proporcionar implementaciones completas, incluidos todos los comportamientos documentados, de cualquier API documentada expuesta por el SDK de Android 2.1 [ Recursos, 4 ].

    Las implementaciones de dispositivos NO DEBEN omitir ninguna API administrada, alterar las interfaces o firmas de API, desviarse del comportamiento documentado ni incluir operaciones no operativas, excepto donde lo permita específicamente esta Definición de compatibilidad.

    3.2. Compatibilidad de API blanda

    Además de las API administradas de la Sección 3.1, Android también incluye una API "suave" importante solo en tiempo de ejecución, en forma de elementos como intenciones, permisos y aspectos similares de las aplicaciones de Android que no se pueden aplicar en la aplicación. tiempo de compilación. Esta sección detalla las API "soft" y los comportamientos del sistema necesarios para la compatibilidad con Android 2.1. Las implementaciones de dispositivos DEBEN cumplir con todos los requisitos presentados en esta sección.

    3.2.1. Permisos

    Los implementadores de dispositivos DEBEN admitir y hacer cumplir todas las constantes de permisos según lo documentado en la página de referencia de permisos [ Recursos, 5 ]. Tenga en cuenta que la Sección 10 enumera requisitos adicionales relacionados con el modelo de seguridad de Android.

    3.2.2. Parámetros de compilación

    Las API de Android incluyen una serie de constantes en la clase android.os.Build [ Recursos, 6 ] que están destinadas a describir el dispositivo actual. Para proporcionar valores coherentes y significativos en todas las implementaciones de dispositivos, la siguiente tabla incluye restricciones adicionales sobre los formatos de estos valores a los que DEBEN ajustarse las implementaciones de dispositivos.

    Parámetro Comentarios
    android.os.Build.VERSION.RELEASE La versión del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este campo DEBE tener uno de los valores de cadena definidos en [ Recursos, 7 ].
    android.os.Build.VERSION.SDK La versión del sistema Android que se está ejecutando actualmente, en un formato accesible al código de aplicación de terceros. Para Android 2.1, este campo DEBE tener el valor entero 7.
    android.os.Build.VERSION.INCREMENTAL Un valor elegido por el implementador del dispositivo que designa la compilación específica del sistema Android que se está ejecutando actualmente, en formato legible por humanos. Este valor NO DEBE reutilizarse para diferentes compilaciones enviadas a los usuarios finales. Un uso típico de este campo es indicar qué número de compilación o identificador de cambio de control de fuente se utilizó para generar la compilación. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
    android.os.Build.BOARD Un valor elegido por el implementador del dispositivo que identifica el hardware interno específico utilizado por el dispositivo, en formato legible por humanos. Un posible uso de este campo es indicar la revisión específica de la placa que alimenta el dispositivo. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
    android.os.Build.BRAND Un valor elegido por el implementador del dispositivo que identifica el nombre de la empresa, organización, individuo, etc. que produjo el dispositivo, en formato legible por humanos. Un posible uso de este campo es indicar el OEM y/o el proveedor que vendió el dispositivo. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
    android.os.Build.DEVICE Un valor elegido por el implementador del dispositivo que identifica la configuración o revisión específica del cuerpo (a veces llamado "diseño industrial") del dispositivo. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
    android.os.Build.FINGERPRINT Una cadena que identifica de forma única esta compilación. DEBE ser razonablemente legible por humanos. DEBE seguir esta plantilla:
    $(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
    Por ejemplo:
    acme/mydevice/generic/generic:2.1-update1/ERC77/3359:userdebug/test-keys
    La huella digital NO DEBE incluir espacios. Si otros campos incluidos en la plantilla anterior tienen espacios, DEBEN reemplazarse con el carácter de guión bajo ASCII ("_") en la huella digital.
    android.os.Build.HOST Una cadena que identifica de forma única el host en el que se creó la compilación, en formato legible por humanos. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
    android.os.Build.ID Un identificador elegido por 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 significativo para que los usuarios finales distingan entre compilaciones de software. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
    android.os.Build.MODEL Un valor elegido por el implementador del dispositivo que contiene el nombre del dispositivo tal como lo conoce el usuario final. Este 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 o una cadena vacía ("").
    android.os.Build.PRODUCT Un valor elegido por el implementador del dispositivo que contiene el nombre de desarrollo o el nombre en código del dispositivo. DEBE ser legible por humanos, pero no necesariamente está destinado a ser visto por usuarios finales. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").
    android.os.Build.TAGS Una lista separada por comas de etiquetas elegidas por el implementador del dispositivo que distinguen aún más la compilación. Por ejemplo, "sin firmar, depurar". Este campo NO DEBE ser nulo o una cadena vacía (""), pero una sola etiqueta (como "liberación") está bien.
    android.os.Build.TIME Un valor que representa la marca de tiempo en la que se produjo la compilación.
    android.os.Build.TYPE Un valor elegido por el implementador del dispositivo que especifica la configuración de tiempo de ejecución de la compilación. Este campo DEBE tener uno de los valores correspondientes a las tres configuraciones típicas de tiempo de ejecución de Android: "user", "userdebug" o "eng".
    android.os.Build.USER Un nombre o ID de usuario del usuario (o usuario automatizado) que generó la compilación. No hay requisitos sobre el formato específico de este campo, excepto que NO DEBE ser nulo o una cadena vacía ("").

    3.2.3. Compatibilidad de intenciones

    Android utiliza intenciones para lograr una integración débil entre aplicaciones. Esta sección describe los requisitos relacionados con los patrones de intención que DEBEN ser respetados por las implementaciones de dispositivos. Por "honrado" se entiende que el implementador del dispositivo DEBE proporcionar una Actividad o Servicio de Android que especifique un filtro de Intención coincidente y se vincule e implemente el comportamiento correcto para cada patrón de Intención especificado.

    3.2.3.1. Intenciones de las aplicaciones principales

    El proyecto ascendente de Android define una serie de aplicaciones principales, como un marcador telefónico, un calendario, una libreta de contactos, un reproductor de música, etc. Los implementadores de dispositivos PUEDEN reemplazar estas aplicaciones con versiones alternativas.

    Sin embargo, cualquiera de estas versiones alternativas DEBE respetar los mismos patrones de intención proporcionados por el proyecto inicial. Por ejemplo, si un dispositivo contiene un reproductor de música alternativo, aún debe respetar el patrón de intención emitido por aplicaciones de terceros para elegir una canción.

    Las siguientes aplicaciones se consideran aplicaciones principales del sistema Android:

    • Escritorio Reloj
    • Navegador
    • Calendario
    • Calculadora
    • Cámara
    • Contactos
    • Galería
    • de correo electrónico
    • GlobalSearch
    • Launcher
    • LivePicker (es decir, la aplicación de selección de Live Wallpaper; PUEDE omitirse si el dispositivo no admite Live Wallpapers, según la Sección 3.8.5. )
    • Mensajería (también conocida como "Mms")
    • Música
    • Configuración
    • del teléfono
    • Grabadora de sonido

    Las aplicaciones principales del sistema Android incluyen varios componentes de Actividad o Servicio que se consideran "públicos". Es decir, el atributo "android:exportado" puede estar ausente o puede tener el valor "verdadero".

    Para cada Actividad o Servicio definido en una de las aplicaciones principales del sistema Android que no esté marcado como no público mediante un atributo android:exportado con el valor "falso", las implementaciones del dispositivo DEBEN incluir un componente del mismo tipo que implemente el mismo filtro de Intención. patrones como la aplicación principal del sistema Android.

    En otras palabras, la implementación de un dispositivo PUEDE reemplazar las aplicaciones principales del sistema Android; sin embargo, si es así, la implementación del dispositivo DEBE admitir todos los patrones de intención definidos por cada aplicación principal del sistema Android que se reemplaza.

    3.2.3.2. Anulación de intenciones

    Como Android es una plataforma extensible, los implementadores de dispositivos DEBEN permitir que cada patrón de intención definido en las aplicaciones principales del sistema sea anulado por aplicaciones de terceros. El proyecto de código abierto de Android permite esto de forma predeterminada; Los implementadores de dispositivos NO DEBEN otorgar privilegios especiales al uso de estos patrones de Intent por parte de las aplicaciones del sistema, ni evitar que aplicaciones de terceros se vinculen y asuman el control de estos patrones. Esta prohibición incluye específicamente, entre otras, la desactivación de la interfaz de usuario "Selector", que permite al usuario seleccionar entre múltiples aplicaciones que manejan el mismo patrón de intención.

    Nota: esta sección fue modificada por Erratum EX6580.

    3.2.3.3. Espacios de nombres de intención

    Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respete cualquier nuevo patrón de intención o intención de transmisión mediante una ACCIÓN, CATEGORÍA u otra cadena clave en el espacio de nombres android.*. Los implementadores de dispositivos NO DEBEN incluir ningún componente de Android que respete cualquier nuevo patrón de Intención o Intención de transmisión utilizando una ACCIÓN, CATEGORÍA u otra cadena clave en un espacio de paquete que pertenece a otra organización. Los implementadores de dispositivos NO DEBEN alterar ni ampliar ninguno de los patrones de Intención utilizados por las aplicaciones principales enumeradas en la Sección 3.2.3.1.

    Esta prohibición es análoga a la especificada para las clases de lenguaje Java en la Sección 3.6.

    3.2.3.4. Intentos de transmisión Las

    aplicaciones de terceros dependen de la plataforma para transmitir ciertos Intents y notificarles sobre 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 apropiados del sistema. Las intenciones de transmisión se describen en la documentación del SDK.

    3.3. Compatibilidad de API nativa

    El código administrado que se ejecuta en Dalvik puede llamar al código nativo proporcionado en el archivo .apk de la aplicación como un archivo ELF .so compilado para la arquitectura de hardware del dispositivo adecuada. Las implementaciones de dispositivos DEBEN incluir soporte para el código que se ejecuta en el entorno administrado para llamar al código nativo, utilizando la semántica estándar de la interfaz nativa de Java (JNI). Las siguientes API DEBEN estar disponibles para el código nativo:

    • libc (biblioteca C)
    • libm (biblioteca matemática)
    • Interfaz JNI
    • libz (compresión Zlib)
    • liblog (registro de Android)
    • Compatibilidad mínima con C++
    • Compatibilidad con OpenGL, como se describe a continuación
      • Las

    implementaciones de dispositivos DEBEN admitir OpenGL ES 1.0 . Los dispositivos que carecen de aceleración de hardware DEBEN implementar OpenGL ES 1.0 mediante un renderizador de software. Las implementaciones de dispositivos DEBEN implementar tanto OpenGL ES 1.1 como admita el hardware del dispositivo. Las implementaciones de dispositivos DEBEN proporcionar una implementación para OpenGL ES 2.0, si el hardware es capaz de ofrecer un rendimiento razonable en esas API.

    Estas bibliotecas DEBEN ser compatibles con el código fuente (es decir, con el encabezado) y con el código binario (para una arquitectura de procesador determinada) con las versiones proporcionadas en Bionic por el proyecto de código abierto de Android. Dado que las implementaciones de Bionic no son totalmente compatibles con otras implementaciones como la biblioteca GNU C, los implementadores de dispositivos DEBEN usar la implementación de Android. Si los implementadores de dispositivos utilizan una implementación diferente de estas bibliotecas, DEBEN garantizar la compatibilidad de encabezado, binaria y de comportamiento.

    Las implementaciones de dispositivos DEBEN informar con precisión la interfaz binaria de aplicación (ABI) nativa admitida por el dispositivo, a través de la API android.os.Build.CPU_ABI . La ABI DEBE ser una de las entradas documentadas en la última versión del NDK de Android, en el archivo docs/CPU-ARCH-ABIS.txt . Tenga en cuenta que las versiones adicionales del NDK de Android pueden introducir compatibilidad con ABI adicionales.

    La compatibilidad del código nativo es un desafío. Por esta razón, se debe repetir que se recomienda MUY fuertemente a los implementadores de dispositivos que utilicen las implementaciones ascendentes de las bibliotecas enumeradas anteriormente, para ayudar a garantizar la compatibilidad.

    3.4. Compatibilidad de API web

    Muchos desarrolladores y aplicaciones dependen del comportamiento de la clase android.webkit.WebView [ Recursos, 8 ] para sus interfaces de usuario, por lo que la implementación de WebView debe ser compatible con todas las implementaciones de Android. La implementación de Android Open Source utiliza el motor de renderizado WebKit para implementar WebView.

    Debido a que no es factible desarrollar un conjunto de pruebas integral para un navegador web, los implementadores de dispositivos DEBEN usar la compilación ascendente específica de WebKit en la implementación de WebView. Específicamente:

    • WebView DEBE usar la compilación WebKit 530.17 del árbol de código abierto de Android para Android 2.1. Esta compilación incluye un conjunto específico de funcionalidades y correcciones de seguridad para WebView.
    • La cadena del agente de usuario informada por WebView DEBE tener este formato:
      Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
      • de La cadena $(VERSION) DEBE ser el mismo que el valor de android.os.Build.VERSION.RELEASE
      • El valor de la cadena $(LOCALE) DEBE seguir las convenciones ISO para el código de país y el idioma, y ​​DEBE hacer referencia a la configuración regional actual del dispositivo
      • El valor de la cadena $(MODEL) DEBE ser el mismo que el valor de android.os.Build.MODEL
      • El valor de la cadena $(BUILD) DEBE ser el mismo que el valor de android.os.Build.ID
    Las implementaciones
      • android.os.Build.ID

    PUEDEN incluir una cadena de agente de usuario personalizada en la aplicación de navegador independiente. Es más, el navegador independiente PUEDE basarse en una tecnología de navegador alternativa (como Firefox, Opera, etc.). Sin embargo, incluso si se envía una aplicación de navegador alternativa, el componente WebView proporcionado a aplicaciones de terceros DEBE estar basado en WebKit. como anteriormente.

    La configuración de WebView DEBE incluir soporte para la base de datos HTML5, caché de aplicaciones y API de geolocalización [ Recursos, 9 ]. WebView DEBE incluir soporte para la etiqueta HTML5 <video> de alguna forma. La aplicación de navegador independiente (ya sea basada en la aplicación de navegador WebKit anterior o en un reemplazo de terceros) DEBE incluir soporte para las mismas funciones HTML5 que se acaban de enumerar para WebView.

    3.5. Compatibilidad del comportamiento de API

    El comportamiento de cada uno de los tipos de API (administrado, suave, nativo y web) debe ser coherente con la implementación preferida del proyecto de código abierto de Android [ Recursos, 3 ]. Algunas áreas específicas de compatibilidad son:

    • Los dispositivos NO DEBEN cambiar el comportamiento o significado de una Intención estándar
    • Los dispositivos NO DEBEN alterar el ciclo de vida o la semántica del ciclo de vida de un tipo particular de componente del sistema (como Servicio, Actividad, Proveedor de contenido, etc.)
    • Los dispositivos NO DEBEN cambiar la semántica de un permiso en particular

    La lista anterior no es exhaustiva y la responsabilidad de garantizar la compatibilidad del comportamiento recae en los implementadores del dispositivo. Por esta razón, los implementadores de dispositivos DEBEN utilizar 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 importantes del sistema.

    El Compatibility Test Suite (CTS) prueba partes importantes de la plataforma para determinar la compatibilidad del comportamiento, pero no todas. Es responsabilidad del implementador garantizar la compatibilidad del comportamiento con el Proyecto de código abierto de Android.

    3.6. API Namespaces

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

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

    Las modificaciones prohibidas incluyen: Las

    • implementaciones de dispositivos DEBEN NO modifique las API expuestas públicamente en la plataforma Android cambiando ningún método o firma de clase, ni eliminando clases o campos de clase.
    • Los implementadores de dispositivos PUEDEN modificar la implementación subyacente de las API, pero dichas modificaciones NO DEBEN afectar el comportamiento declarado ni la firma en lenguaje Java de las API expuestas 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 API anteriores.

    Un "elemento expuesto públicamente" es cualquier construcción que no esté decorada con el marcador "@hide" en el código fuente de Android. En otras palabras, los implementadores de dispositivos NO DEBEN exponer nuevas API ni alterar las API existentes en los espacios de nombres mencionados anteriormente. Los implementadores de dispositivos PUEDEN realizar modificaciones solo internas, pero esas modificaciones NO DEBEN publicitarse ni exponerse de otro modo a los desarrolladores.

    Los implementadores de dispositivos PUEDEN agregar API personalizadas, pero dichas API NO DEBEN estar en un espacio de nombres que sea propiedad de otra organización o que haga referencia a ella. Por ejemplo, los implementadores de dispositivos NO DEBEN agregar API al com.google.* o espacio de nombres similar; sólo Google puede hacerlo. De manera similar, Google NO DEBE agregar API a los espacios de nombres de otras empresas.

    Si un implementador de dispositivo propone mejorar uno de los espacios de nombres de paquetes anteriores (por ejemplo, agregando nuevas funciones útiles a una API existente o agregando una nueva API), 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.

    Tenga en cuenta que las restricciones anteriores corresponden a convenciones estándar para nombrar API en el lenguaje de programación Java; Esta sección simplemente tiene como objetivo reforzar esas convenciones y hacerlas vinculantes mediante su inclusión en esta definición de compatibilidad.

    3.7.

    Las implementaciones de dispositivos

    de compatibilidad de máquinas virtuales

    DEBEN admitir la especificación completa del código de bytes Dalvik Executable (DEX) y la semántica de la máquina virtual Dalvik [ Recursos, 10 ].

    Las implementaciones de dispositivos DEBEN configurar Dalvik para asignar al menos 16 MB de memoria a cada aplicación en dispositivos con pantallas clasificadas como de densidad media o baja. Las implementaciones de dispositivos DEBEN configurar Dalvik para asignar al menos 24 MB de memoria a cada aplicación en dispositivos con pantallas clasificadas como de alta densidad. Tenga en cuenta que las implementaciones de dispositivos PUEDEN asignar más memoria que estas cifras, pero no es necesario.

    3.8. Compatibilidad de la interfaz de usuario

    La plataforma Android incluye algunas API de desarrollador que permiten a los desarrolladores conectarse a la interfaz de usuario del sistema. Las implementaciones de dispositivos DEBEN incorporar estas API de UI estándar en interfaces de usuario personalizadas que desarrollen, como se explica a continuación.

    3.8.1. Widgets

    Android define un tipo de componente y la API y el ciclo de vida correspondientes que permiten a las aplicaciones exponer un "AppWidget" al usuario final [ Recursos, 11 ]. La versión de referencia de código abierto de Android incluye una aplicación de inicio que incluye elementos de interfaz de usuario que permiten al usuario agregar, ver y eliminar AppWidgets de la pantalla de inicio.

    Los implementadores de dispositivos PUEDEN sustituir una alternativa al Iniciador de referencia (es decir, la pantalla de inicio). Los lanzadores alternativos DEBEN incluir soporte integrado para AppWidgets y exponer elementos de la interfaz de usuario para agregar, configurar, ver y eliminar AppWidgets directamente dentro del Lanzador. Los lanzadores alternativos PUEDEN omitir estos elementos de la interfaz de usuario; sin embargo, si se omiten, el implementador del dispositivo DEBE proporcionar una aplicación separada accesible desde el Iniciador que permita a los usuarios agregar, configurar, ver y eliminar AppWidgets.

    3.8.2. Notificaciones

    Android incluye API que permiten a los desarrolladores notificar a los usuarios sobre eventos notables [ Recursos, 12 ]. Los implementadores de dispositivos DEBEN brindar soporte para cada clase de notificación así definida; en concreto: sonidos, vibración, luz y barra de estado.

    Además, la implementación DEBE representar correctamente todos los recursos (iconos, archivos de sonido, etc.) proporcionados en las API [ Recursos, 13 ], o en la guía de estilo de iconos de la barra de estado [ Recursos, 14 ]. Los implementadores de dispositivos PUEDEN proporcionar una experiencia de usuario alternativa para las notificaciones a la proporcionada por la implementación de código abierto de Android de referencia; sin embargo, dichos sistemas de notificación alternativos DEBEN respaldar los recursos de notificación existentes, como se indicó anteriormente.

    Android incluye API [ Recursos, 15 ] que permiten a los desarrolladores incorporar búsquedas en sus aplicaciones y exponer los datos de sus aplicaciones en la búsqueda global del sistema. En términos generales, esta funcionalidad consta de una única interfaz de usuario para todo el sistema que permite a los usuarios ingresar consultas, muestra sugerencias a medida que los usuarios escriben y muestra resultados. Las API de Android permiten a los desarrolladores reutilizar esta interfaz para realizar búsquedas dentro de sus propias aplicaciones y 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 realizar sugerencias en tiempo real en respuesta a las entradas del usuario. Las implementaciones de dispositivos DEBEN implementar las API que permitan a los desarrolladores reutilizar esta interfaz de usuario para realizar búsquedas dentro de sus propias aplicaciones. Las implementaciones de dispositivos DEBEN implementar las API que permiten que las aplicaciones de terceros agreguen sugerencias al cuadro de búsqueda cuando se ejecuta en modo de búsqueda global. Si no hay aplicaciones de terceros instaladas que utilicen esta funcionalidad, el comportamiento predeterminado DEBE ser mostrar resultados y sugerencias del motor de búsqueda web.

    Las implementaciones de dispositivos PUEDEN incluir interfaces de usuario de búsqueda alternativas, pero DEBEN incluir un botón de búsqueda dedicado físico o virtual, que se puede usar en cualquier momento dentro de cualquier aplicación para invocar el marco de búsqueda, con el comportamiento previsto en la documentación de la API.

    3.8.4.

    Las aplicaciones

    Toast

    pueden usar la API "Toast" (definida en [ Recursos, 16 ]) para mostrar cadenas cortas no modales al usuario final, que desaparecen después de un breve período de tiempo. Las implementaciones de dispositivos DEBEN mostrar los brindis de las aplicaciones a los usuarios finales de alguna manera de alta visibilidad.

    3.8.5. Live Wallpapers

    Android define un tipo de componente y su API y ciclo de vida correspondientes que permiten a las aplicaciones exponer uno o más "Live Wallpapers" al usuario final [ Recursos, 17 ]. Los fondos de pantalla animados son animaciones, patrones o imágenes similares con capacidades de entrada limitadas que se muestran como fondo de pantalla, detrás de otras aplicaciones.

    Se considera que el hardware es capaz de ejecutar de manera confiable fondos de pantalla en vivo si puede ejecutar todos los fondos de pantalla en vivo, sin limitaciones de funcionalidad, a una velocidad de fotogramas razonable y sin efectos adversos en otras aplicaciones. Si las limitaciones del hardware provocan que los fondos de pantalla y/o las aplicaciones fallen, funcionen mal, consuman demasiada energía de la CPU o de la batería, o se ejecuten a velocidades de fotogramas inaceptablemente bajas, se considera que el hardware es incapaz de ejecutar fondos de pantalla en vivo. Por ejemplo, algunos fondos de pantalla animados pueden utilizar un contexto Open GL 1.0 o 2.0 para representar su contenido. El fondo de pantalla en vivo no se ejecutará de manera confiable en hardware que no admita múltiples contextos OpenGL porque el uso del fondo de pantalla en vivo de un contexto OpenGL puede entrar en conflicto con otras aplicaciones que también usan un contexto OpenGL.

    Las implementaciones de dispositivos capaces de ejecutar fondos de pantalla en vivo de manera confiable, como se describe anteriormente, DEBEN implementar fondos de pantalla en vivo. Las implementaciones de dispositivos que se determine que no ejecutan fondos de pantalla en vivo de manera confiable, como se describe anteriormente, NO DEBEN implementar fondos de pantalla en vivo.

    4. Compatibilidad del software de referencia

    Los implementadores de dispositivos DEBEN probar la compatibilidad de la implementación utilizando las siguientes aplicaciones de código abierto:

    • Calculadora (incluida en el SDK)
    • Lunar Lander (incluida en el SDK)
    • Las aplicaciones "Aplicaciones para Android" [ Recursos, 18 ].

    Cada aplicación anterior DEBE iniciarse y comportarse correctamente en la implementación, para que la implementación se considere compatible.

    Además, las implementaciones de dispositivos DEBEN probar cada elemento del menú (incluidos todos los submenús) de cada una de estas aplicaciones de prueba de humo:

    • ApiDemos (incluido en SDK)
    • ManualSmokeTests (incluido en CTS)

    Cada caso de prueba en las aplicaciones anteriores DEBE ejecutarse correctamente en el dispositivo implementación.

    5. Compatibilidad del empaquetado de aplicaciones

    Las implementaciones de dispositivos DEBEN instalar y ejecutar archivos ".apk" de Android generados por la herramienta "aapt" incluida en el SDK oficial de Android [ Recursos, 19 ].

    Las implementaciones de dispositivos NO DEBEN extender los formatos .apk [ Recursos, 20 ], Android Manifest [ Recursos, 21 ] o Dalvik bytecode [ Recursos, 10 ] de tal manera que impida que esos archivos se instalen y ejecuten correctamente en otros dispositivos compatibles. . Los implementadores de dispositivos DEBEN utilizar la implementación ascendente de referencia de Dalvik y el sistema de gestión de paquetes de la implementación de referencia.

    6.

    Las implementaciones de dispositivos de compatibilidad multimedia DEBEN admitir los siguientes códecs multimedia. Todos estos códecs se proporcionan como implementaciones de software en la implementación de Android preferida del Proyecto de código abierto de Android.

    Tenga en cuenta que ni Google ni Open Handset Alliance hacen ninguna declaración de que estos códecs no estén gravados por patentes de terceros. Se advierte a quienes deseen utilizar este código fuente en productos de hardware o software que las implementaciones de este código, incluso en software de código abierto o shareware, pueden requerir licencias de patente de los titulares de patentes correspondientes.

    Nombre Velocidades PCM lineal de onda (.WAV)
    de audio
    Codificador Decodificador Detalles Archivo /Contenedor Formato
    AAC LC/LTP   X Contenido mono/estéreo en cualquier combinación de velocidades de bits estándar de hasta 160 kbps y velocidades de muestreo entre 8 y 48 kHz 3GPP (.3gp) y MPEG-4 (.mp4, .m4a). No hay soporte para AAC sin formato (.aac)
    HE-AACv1 (AAC+)   X
    HE-AACv2 (AAC+ mejorado)   X
    AMR-NB X X 4,75 a 12,2 kbps muestreados a 8 kHz 3GPP (.3gp)
    AMR-WB  X 9 de 6,60 kbit/s a 23,85 kbit/s muestreados a 16 kHz 3GPP (.3gp)
    MP3   X Mono/Estéreo 8-320 Kbps velocidad de bits constante (CBR) o variable (VBR) MP3 (.mp3)
    MIDI   X MIDI Tipo 0 y 1. DLS Versión 1 y 2. XMF y XMF móvil. Soporte para formatos de tono de llamada RTTTL/RTX, OTA e Imelody tipo 0 y 1 (.MID, .xmf, .mxmf). También rtttl/rtx (.rtttl, .rtx), OTA (.ota) e imelody (.imy)
    ogg vorbis   X   OGG (.OGG)
    PCM  de 8 y 16 bits (tasas hasta el límite del hardware )
    Imagen
    JPEG X X Base+Progressive  
    GIF   X   
    PNG x x   
    BMP   X   
    Video
    H.263 X X   Archivos 3GPP (.3GP)
    H.264   X   Archivos 3GPP (.3GP) y MPEG-4 (.MP4)
    MPEG4 Perfil simple   X   Archivo 3GPP (.3GP)

    Tenga en cuenta que la tabla anterior no enumera los requisitos específicos de la tasa de bits para la mayoría de los códecs de video. La razón de esto es que en la práctica, el hardware actual del dispositivo no necesariamente admite tasas de bits que se asignan exactamente a las tasas de bits requeridas especificadas por los estándares relevantes. En cambio, las implementaciones del dispositivo deben admitir la práctica de la tasa de bits más alta en el hardware, hasta los límites definidos por las especificaciones.

    7.

    Las implementaciones del dispositivo de compatibilidad con la herramienta de desarrollador deben admitir las herramientas de desarrollador de Android proporcionadas en el SDK de Android. Específicamente, los dispositivos compatibles con Android deben ser compatibles con:

    • Android Debug Bridge (conocido como ADB) [ Recursos, 19 ]
      Las implementaciones de dispositivos deben admitir todas las funciones adb como se documenta en el SDK de Android. El demonio adb del lado del dispositivo debe estar inactivo de forma predeterminada, pero debe haber un mecanismo accesible para el usuario para activar el puente de depuración de Android.
    • Servicio de monitor de depuración de Dalvik (conocido como DDMS) [ Recursos, 19 ]
      Las implementaciones de dispositivos deben admitir todas las características ddms según lo documentado en el SDK de Android. Como ddms usa adb , el soporte para ddms debe estar inactivo de forma predeterminada, pero debe ser compatible cada vez que el usuario haya activado el puente de depuración de Android, como se indicó anteriormente.
    • Mono [ Recursos, 22 ]
      Las implementaciones de dispositivos deben incluir el marco de mono y ponerlo a disposición de las aplicaciones que los usen.

    8. Compatibilidad de hardware

    Android está destinado a admitir implementadores de dispositivos que crean factores y configuraciones de forma innovadores. Al mismo tiempo, los desarrolladores de Android esperan ciertos hardware, sensores y API en todos los dispositivos Android. Esta sección enumera las características de hardware que todos los dispositivos compatibles con Android 2.1 deben admitir.

    Si un dispositivo incluye un componente de hardware particular que tiene una API correspondiente para desarrolladores de terceros, la implementación del dispositivo debe implementar esa API como se define en la documentación SDK de Android. Si una API en el SDK interactúa con un componente de hardware que se considera opcional y la implementación del dispositivo no posee ese componente: las

    • definiciones de clase para las API del componente deben estar presentes
    • los comportamientos de la API deben implementarse como no-op-op-OPS de alguna manera razonable
    • Los métodos de API deben devolver los valores nulos cuando lo permitan la documentación SDK Los
    • métodos API deben devolver implementaciones de clases no-op de clases donde los valores nulos no están permitidos por la documentación SDK,

    un ejemplo típico de un escenario en el que se aplican estos requisitos es la API de telefonía: incluso en no en que no -Dispositivos de teléfonos, estas API deben implementarse como no-OPS razonables.

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

    8.1. Display

    Android 2.1 incluye instalaciones que realizan ciertas operaciones automáticas de escala y transformación en algunas circunstancias, para garantizar que las aplicaciones de terceros funcionen razonablemente bien en una variedad de configuraciones de hardware [ recursos, 23 ]. Los dispositivos deben implementar adecuadamente estos comportamientos, como se detalla en esta sección.

    Para Android 2.1, estas son las configuraciones de visualización más comunes:

    altura Implementaciones de dispositivo medio grande de gran tamaño de dispositivo medio grande de dispositivo
    de tipo de pantalla de tipo de pantalla (píxeles) altura (píxeles) Rango de longitud diagonal (pulgadas) Tamaño de pantalla Densidad de pantalla Densidad de pantalla
    QVGA 240 320 2.6 - 3.0 Pequeño
    WQVGA 240 400 3.2 - 3.5 Normal bajo bajo
    FWQVGA 240 432 3.5 - 3.8 Normal bajo
    HVGA 320 480 3.0 - 3.5 Medio normal
    WVGA 480 800 3.3 - 4.0 Normal High
    FWVGA 480 854 3.5 - 4.0 Normal HIGH
    WVGA 480 800 4.8 - 5.5 FWVGA MEDIO
    480 854 5.0 - 5.8mediano grande

    . correspondiente a una de las configuraciones estándar anteriores debe configurarse para informar el tamaño de pantalla indicado a las aplicaciones a través de la clase android.content.res.Configuration [ recursos, 24 ].

    Algunos paquetes .APK tienen manifiestos que no los identifican como admitir un rango de densidad específico. Al ejecutar dichas aplicaciones, se aplican las siguientes restricciones:

    • las implementaciones de dispositivos deben interpretar los recursos en un .apk que carecen de un calificador de densidad como predeterminado a "medio" (conocido como "MDPI" en la documentación SDK).
    • Al operar con una densidad "baja" Las implementaciones de la pantalla, el dispositivo deben escalar activos medios/MDPI en un factor de 0.75.
    • Al operar en una pantalla de densidad "alta", las implementaciones de dispositivos deben ampliar los activos de Medium/MDPI en un factor de 1.5.
    • Las implementaciones del dispositivo no deben escalar activos dentro de un rango de densidad, y deben escalar activos por exactamente estos factores entre los rangos de densidad.

    8.1.2. Configuraciones de visualización no estándar

    Configuraciones de visualización que no coinciden con una de las configuraciones estándar enumeradas en la Sección 8.1.1 requieren una consideración y trabajo adicionales para ser compatibles. Los implementadores de dispositivos deben comunicarse con el equipo de Compatibilidad de Android según lo dispuesto en la Sección 12 para obtener clasificaciones para el cubo, la densidad y el factor de escala del tamaño de una pantalla. Cuando se le proporciona esta información, las implementaciones del dispositivo deben implementarlas como se especifica.

    Tenga en cuenta que algunas configuraciones de visualización (como pantallas muy grandes o muy pequeñas, y algunas relaciones de aspecto) son fundamentalmente incompatibles con Android 2.1; Por lo tanto, se alienta a los implementadores de dispositivos a comunicarse con el equipo de compatibilidad de Android lo antes posible en el proceso de desarrollo.

    8.1.3.

    Las implementaciones de dispositivos

    de métricos de visualización

    deben informar valores correctos para todas las métricas de visualización definidas en android.util.DisplayMetrics [ recursos, 25 ].

    8.2.

    Implementaciones de dispositivos del dispositivo

    del teclado

    :

    • debe incluir soporte para el marco de administración de entrada (que permite a los desarrolladores de terceros crear motores de gestión de entrada, es decir, teclado suave) como se detalla en desarrollador.android.com
    • debe proporcionar al menos una implementación de teclado suave (independientemente de si un El teclado duro está presente)
    • puede incluir implementaciones adicionales de teclado suave
    • que pueden incluir un teclado de hardware
    • que no debe incluir un teclado de hardware que no coincida con uno de los formatos especificados en android.content.res.Configuration.keyboard [ recursos, 24 ] (es decir,, es, Qwerty, o 12-clave)

    8.3.

    Implementaciones de dispositivos

    de navegación que no son de toque

    :
    • pueden omitir una opción de navegación no táctil (es decir, puede omitir una bola de seguimiento, D-Pad o Wheel)
    • debe informar el valor correcto para android.content.res.Configuration.navigation [ recursos, 24 ]

    8.4.

    Los dispositivos compatibles

    con la orientación de la pantalla

    deben admitir la orientación dinámica mediante aplicaciones a la orientación de la pantalla de retrato o paisaje. Es decir, el dispositivo debe respetar la solicitud de la aplicación de una orientación de pantalla específica. Las implementaciones de dispositivos pueden seleccionar la orientación de retrato o paisaje como predeterminado.

    Los dispositivos deben informar el valor correcto para la orientación actual del dispositivo, siempre que se consulte a través de android.content.res.configuration.orientation, android.view.display.getorientation () u otras API.

    8.5.

    Implementaciones de dispositivos

    de entrada de pantalla táctil

    :

    • debe tener una pantalla táctil
    • puede tener una pantalla táctil capacitada o resistiva
    • debe informar el valor de android.content.res.Configuration [ recursos, 24 ] reflejando correspondiente al tipo de pantalla táctil específica en el dispositivo

    8.6.

    Implementaciones del dispositivo

    USB

      :
    • debe implementar un cliente USB, conectable a un host USB con un puerto USB-A estándar
    • debe implementar el puente de depuración de Android a través de USB (como se describe en la Sección 7)
    • , debe implementar la especificación de almacenamiento masivo USB, para permitir que un host conectado al dispositivo para acceder al contenido del volumen /sdcard
    • debe usar el factor de forma micro USB en el lado del dispositivo
    • puede incluir un puerto no estándar en el lado del dispositivo, pero de ser así, debe enviar con un cable capaz de conectar el pinout personalizado a Puerto USB-A estándar

    8.7. Cayos de navegación

    El inicio, el menú y las funciones posteriores son esenciales para el paradigma de navegación de Android. Las implementaciones de dispositivos deben hacer que estas funciones estén disponibles para el usuario en todo momento, independientemente del estado de la aplicación. Estas funciones deben implementarse a través de botones dedicados. Se pueden implementar utilizando software, gestos, panel táctil, etc., pero si es así, siempre deben ser accesibles y no oscurecer o interferir con el área de visualización de aplicaciones disponible.

    Los implementadores de dispositivos también deben proporcionar una clave de búsqueda dedicada. Los implementadores de dispositivos también pueden proporcionar claves de envío y finalización para llamadas telefónicas.

    8.8.

    Las implementaciones de dispositivos

    de redes de datos inalámbricos

    deben incluir soporte para redes inalámbricas de datos de alta velocidad. Específicamente, las implementaciones del dispositivo deben incluir soporte para al menos un estándar de datos inalámbricos capaces de 200 kbit/seg o más. Ejemplos de tecnologías que satisfacen este requisito incluyen Edge, HSPA, EV-DO, 802.11g, etc.

    Si una implementación de un dispositivo incluye una modalidad particular para la cual el SDK de Android incluye una API (es decir, WiFi, GSM o CDMA), el La implementación debe admitir la API.

    Los dispositivos pueden implementar más de una forma de conectividad de datos inalámbricos. Los dispositivos pueden implementar la conectividad de datos con cable (como Ethernet), pero, sin embargo, deben incluir al menos una forma de conectividad inalámbrica, como se indicó anteriormente.

    8.9.

    Las implementaciones de dispositivos

    de cámara

    deben incluir una cámara. La cámara incluida:

    • debe tener una resolución de al menos 2 megapíxeles
    • debe tener hardware automático de enfoque o software automático implementado en el controlador de la cámara (transparente al software de aplicación)
    • puede tener enfoque fijo o EDOF (profundidad de campo extendida) El hardware
    • puede incluir un flash. Si la cámara incluye un flash, la lámpara de flash no debe encenderse mientras un android.hardware.camera.previewCallback instancia se ha registrado en una superficie de vista previa de la cámara, a menos que la aplicación haya habilitado explícitamente el flash habilitando los atributos FLASH_MODE_AUTO o FLASH_MODE_ON de A de un Camera.Parameters Objeto de parámetros. Tenga en cuenta que esta restricción no se aplica a la aplicación de cámara del sistema incorporada del dispositivo, sino solo a las aplicaciones de terceros que usan Camera.PreviewCallback .

    Las implementaciones del dispositivo deben implementar los siguientes comportamientos para las API relacionadas con la cámara:

    1. si una aplicación nunca ha llamado android.hardware.camera.parameters.setPreviewFormat (int), entonces el dispositivo debe usar android.hardware.pixelformat.ycbcr_420_sp para los datos de vista previa proporcionadas a Vueltas de llamada de aplicación.
    2. Si una aplicación registra un método android.hardware.camera.previewcallback y el sistema llama al método OnPreviewFrame () Cuando el formato de vista previa es YCBCR_420_SP, los datos en el byte [] pasan a OnpreviewFrame () deben estar más en el formato de codificación NV21. (Este es el formato utilizado de forma nativa por la familia de hardware 7K). Es decir, NV21 debe ser el valor predeterminado.

    Las implementaciones de dispositivos deben implementar la API de cámara completa incluida en la documentación SDK de Android 2.1 [ recursos, 26 ]), independientemente de si el dispositivo incluye enfoque automático de hardware u otras capacidades. Por ejemplo, las cámaras que carecen de enfoque automático aún deben llamar a cualquier android.hardware.Camera.AutoFocusCallback (aunque esto no tiene relevancia para una cámara que no es de autococo). Las implementaciones de

    dispositivos deben reconocer y honrar cada nombre de parámetro definido como una constante en la constante en la constante android.hardware.Camera.Parameters Clase, si el hardware subyacente admite la función. Si el hardware del dispositivo no admite una función, la API debe comportarse como se documenta. Por el contrario, las implementaciones de dispositivos no deben honrar ni reconocer las constantes de cadena pasadas al método android.hardware.Camera.setParameters() que no sean las documentadas como constantes en android.hardware.Camera.Parameters , a menos que las constantes tengan prefijo con una cadena que indica la cadena de las Nombre del implementador del dispositivo. Es decir, las implementaciones de dispositivos deben admitir todos los parámetros de cámara estándar si el hardware lo permite, y no debe admitir tipos de parámetros de cámara personalizados a menos que los nombres de parámetros se indiquen claramente a través de un prefijo de cadena para que no sea estándar.

    8.10.

    Las implementaciones del dispositivo

    del acelerómetro

    deben incluir un acelerómetro de 3 ejes y deben poder entregar eventos a 50 Hz o más. El sistema de coordenadas utilizado por el acelerómetro debe cumplir con el sistema de coordenadas del sensor Android como se detalla en las API de Android (ver [ Recursos, 27 ]).

    8.11.

    Las implementaciones del dispositivo

    Compass

    deben incluir una brújula de 3 ejes y deben poder entregar eventos de 10 Hz o más. El sistema de coordenadas utilizado por la brújula debe cumplir con el sistema de coordenadas del sensor Android como se define en la API de Android (ver [ Recursos, 27 ]).

    8.12.

    Las implementaciones del dispositivo

    GPS

    deben incluir un GPS, y deben incluir alguna forma de técnica de "GPS asistido" para minimizar el tiempo de bloqueo del GPS.

    8.13. La telefonía

    Android 2.1 se puede usar en dispositivos que no incluyen hardware de telefonía. Es decir, Android 2.1 es compatible con dispositivos que no son teléfonos. Sin embargo, si una implementación de un dispositivo incluye la telefonía GSM o CDMA, debe implementar el soporte completo para la API para esa tecnología. Las implementaciones de dispositivos que no incluyen hardware de telefonía deben implementar las API completas como NO-OPS.

    Consulte también la Sección 8.8, redes de datos inalámbricos.

    8.14.

    Las implementaciones de dispositivos

    de memoria y almacenamiento

    deben tener al menos 92 MB de memoria disponible para el kernel y el espacio de usuarios. El 92 MB debe ser además de cualquier memoria dedicada a componentes de hardware como radio, memoria, etc., eso no está bajo el control del núcleo.

    Las implementaciones de dispositivos deben tener al menos 150 MB de almacenamiento no volátil disponible para los datos del usuario. Es decir, la partición /data debe ser de al menos 150 MB.

    Nota: Esta sección fue modificada por Erratum EX6580.

    8.15. Aplicación

    Las implementaciones de dispositivos de almacenamiento compartido deben ofrecer almacenamiento compartido para aplicaciones. El almacenamiento compartido proporcionado debe tener al menos 2 GB de tamaño.

    Las implementaciones de dispositivos deben configurarse con almacenamiento compartido montado de forma predeterminada, "fuera de la caja". Si el almacenamiento compartido no está montado en la ruta de Linux /sdcard , entonces el dispositivo debe incluir un enlace simbólico de Linux desde /sdcard al punto de montaje real.

    Las implementaciones de dispositivos deben aplicar como se documenta el permiso android.permission.WRITE_EXTERNAL_STORAGE en este almacenamiento compartido. El almacenamiento compartido debe ser redactado por cualquier aplicación que obtenga ese permiso.

    Las implementaciones de dispositivos pueden tener hardware para el almacenamiento extraíble accesible para el usuario, como una tarjeta digital segura. Alternativamente, las implementaciones de dispositivos pueden asignar el almacenamiento interno (no removible) como almacenamiento compartido para aplicaciones.

    Independientemente de la forma de almacenamiento compartido utilizado, el almacenamiento compartido debe implementar el almacenamiento en masa USB, como se describe en la Sección 8.6. Como se envía fuera de la caja, el almacenamiento compartido debe montarse con el sistema de archivos FAT.

    Es ilustrativo considerar dos ejemplos comunes. Si una implementación de un dispositivo incluye una ranura para tarjeta SD para satisfacer el requisito de almacenamiento compartido, se debe incluir una tarjeta SD con forma de grasa de 2GB o más grande con el dispositivo como se vende a los usuarios, y debe montarse de manera predeterminada. Alternativamente, si una implementación de un dispositivo utiliza el almacenamiento fijo interno para satisfacer este requisito, ese almacenamiento debe tener un tamaño de 2 GB o más grande y montado en /sdcard (o /sdcard debe ser un enlace simbólico a la ubicación física si está montado en otro lugar.) Nota.)

    Nota. : Esta sección fue agregada por Erratum EX6580.

    8.16.

    Las implementaciones del dispositivo

    Bluetooth

    deben incluir un transceptor Bluetooth. Las implementaciones de dispositivos deben habilitar la API Bluetooth basada en RFCOMM como se describe en la documentación SDK [ Recursos, 29 ]. Las implementaciones de dispositivos deben implementar perfiles Bluetooth relevantes, como A2DP, AVRCP, OBEX, etc., según corresponda para el dispositivo.

    Nota: Esta sección fue agregada por Erratum EX6580.

    9. Compatibilidad del rendimiento

    Uno de los objetivos del programa de compatibilidad de Android es permitir una experiencia de aplicación consistente para los consumidores. Las implementaciones compatibles deben garantizar no solo que las aplicaciones simplemente se ejecuten correctamente en el dispositivo, sino que lo hacen con un rendimiento razonable y una buena experiencia de usuario en general. Las implementaciones de dispositivos deben cumplir con las métricas clave de rendimiento de un dispositivo compatible de Android 2.1 definido en la tabla a continuación:

    Tiempo de lanzamiento de la aplicación de
    comentarios de umbral de rendimiento métrico
    Las siguientes aplicaciones deben iniciarse dentro del tiempo especificado.
    • Navegador: menos de 1300 ms
    • MMS/SMS: menos de 700 ms
    • de alarma de alarma: menos de 650 ms
    		 El tiempo de lanzamiento se mide como el tiempo total para completar la carga de la actividad predeterminada para la aplicación, incluido el tiempo que lleva iniciar el proceso de Linux, cargar el Android Empaque en la VM Dalvik y llame a OnCreate.
    Aplicaciones simultáneas Cuando se han lanzado múltiples aplicaciones, relanzando una aplicación que ya está en funcionamiento después de que se haya lanzado debe tomar menos que el tiempo de lanzamiento original.  

    10.

    Las implementaciones de dispositivos de compatibilidad del modelo de seguridad deben implementar un modelo de seguridad consistente con el modelo de seguridad de la plataforma Android como se define en el documento de referencia de seguridad y permisos en las API [ recursos, 28 ] en la documentación del desarrollador de Android. Las implementaciones de dispositivos deben admitir la instalación de aplicaciones autofirmadas sin requerir ningún permiso/certificado adicionales de terceros/autoridades. Específicamente, los dispositivos compatibles deben admitir los mecanismos de seguridad descritos en las siguientes subsecciones.

    10.1.

    Las implementaciones del dispositivo

    de permisos

    deben admitir el modelo de permisos de Android como se define en la documentación del desarrollador de Android [ recursos, 28 ]. Específicamente, las implementaciones deben hacer cumplir cada permiso definido como se describe en la documentación SDK; No se pueden omitir, alterar o ignorar los permisos. Las implementaciones pueden agregar permisos adicionales, siempre que las nuevas cadenas de ID de permiso no estén en el espacio de nombres de Android.*

    10.2.

    Las implementaciones de dispositivos

    de aislamiento de UID y procesos

    deben admitir el modelo de Sandbox de la aplicación Android, en el que cada aplicación se ejecuta como un UID de estilo UNIX único y en un proceso separado. Las implementaciones de dispositivos deben admitir la ejecución de múltiples aplicaciones como la misma ID de usuario de Linux, siempre que las aplicaciones estén firmadas y construidas correctamente, como se define en la referencia de seguridad y permisos [ Recursos, 28 ].

    10.3.

    Las implementaciones del dispositivo

    de permisos del sistema de archivos

    deben admitir el modelo de permisos de acceso a archivos de Android como se define en la referencia de seguridad y permisos [ recursos, 28 ].

    11. Las implementaciones de dispositivos del suite de prueba de compatibilidad

    deben pasar el Suite de prueba de compatibilidad de Android (CTS) [ recursos, 2 ] disponible en el proyecto de código abierto de Android, utilizando el software de envío final en el dispositivo. Además, los implementadores de dispositivos deben usar la implementación de referencia en el árbol de código abierto de Android tanto como sea posible, y deben garantizar la compatibilidad en casos de ambigüedad en CTS y para cualquier reimplementación de partes del código fuente de referencia.

    El CTS está diseñado para ejecutarse en un dispositivo real. Como cualquier software, el CTS puede contener errores. El CTS se verificará independientemente de esta definición de compatibilidad, y se pueden publicar múltiples revisiones del CTS para Android 2.1. Las implementaciones de dispositivos deben pasar la última versión CTS disponible en el momento en que se completa el software del dispositivo.

    12.

    Las implementaciones de dispositivos de software actualizables deben incluir un mecanismo para reemplazar la totalidad del software del sistema. El mecanismo no necesita realizar actualizaciones "en vivo", es decir, se puede requerir un reinicio de un dispositivo.

    Se puede utilizar cualquier método, siempre que pueda reemplazar la totalidad del software preinstalado en el dispositivo. Por ejemplo, cualquiera de los siguientes enfoques satisfará este requisito:

    • descargas de Over-the-Air (OTA) con actualizaciones fuera de línea a través de
    • actualizaciones de reinicio "atado" a través de USB desde una PC host
    • actualizaciones "fuera de línea" a través de un reinicio y actualización desde un archivo encendido. Almacenamiento extraíble

    El mecanismo de actualización utilizado debe admitir actualizaciones sin limpiar los datos del usuario. Tenga en cuenta que el software Android ascendente incluye un mecanismo de actualización que satisface este requisito.

    Si se encuentra un error en la implementación de un dispositivo después de que se haya lanzado, pero dentro de su vida de producto razonable que se determina en consulta con el equipo de compatibilidad de Android para afectar la compatibilidad de las aplicaciones de los partidos, el implementador del dispositivo debe corregir el error a través de un software Actualización disponible que se puede aplicar según el mecanismo que se acaba de describir.

    13. Póngase en contacto con nosotros,

    puede comunicarse con los autores del documento en compatibilidad@android.com para obtener aclaraciones y para plantear cualquier problema que crea que el documento no cubre.