APIs de Android 3.1

Nivel de API: 12

Para los desarrolladores, la plataforma de Android 3.1 (HONEYCOMB_MR1) está disponible como componente descargable del SDK de Android. La plataforma descargable incluye una biblioteca de Android, una imagen del sistema, un conjunto de máscaras de emulador y mucho más. La plataforma descargable no incluye bibliotecas externas.

Para los desarrolladores, la plataforma Android 3.1 está disponible como componente descargable del SDK de Android. La plataforma descargable incluye una biblioteca de Android, una imagen del sistema, un conjunto de máscaras de emulador y mucho más. Para comenzar a desarrollar o probar con Android 3.1, usa SDK Manager de Android para descargar la plataforma en tu SDK.

Descripción general de la API

En las siguientes secciones, se proporciona una descripción general técnica de las novedades para desarrolladores en Android 3.1, incluidas las funciones nuevas y los cambios en la API de framework desde la versión anterior.

APIs de USB

Android 3.1 presenta nuevas APIs potentes para integrar periféricos conectados con aplicaciones que se ejecutan en la plataforma. Las APIs se basan en una pila USB (bus universal en serie) y en servicios integrados en la plataforma, incluida la compatibilidad con las interacciones del host USB y del dispositivo. Con las APIs, los desarrolladores pueden crear aplicaciones capaces de descubrir, comunicarse con ellos y administrar diversos tipos de dispositivos conectados a través de USB.

La pila y las APIs distinguen dos tipos básicos de hardware USB, en función de si el dispositivo con Android actúa como host o si el hardware externo actúa como host:

  • Un dispositivo USB es una pieza de hardware conectado que depende del dispositivo con tecnología Android para que funcione como host. Por ejemplo, la mayoría de los dispositivos de entrada, los mouse y los joysticks son dispositivos USB, al igual que muchas cámaras, concentradores, etcétera.
  • Un accesorio USB es una pieza de hardware conectado que tiene un control host USB, proporciona energía y está diseñado para comunicarse con dispositivos Android mediante USB. Varios periféricos pueden conectarse como accesorios, desde controladores robóticos hasta equipos musicales, bicicletas estáticas y mucho más.

Para ambos tipos (dispositivos USB y accesorios USB), las APIs de USB de la plataforma admiten el descubrimiento por transmisión de intents cuando se conecta o desconecta, además de interfaces, extremos y modos de transferencia estándar (de control, de interrupción y masivo).

Las APIs de USB están disponibles en el paquete android.hardware.usb. La clase central es UsbManager, que proporciona métodos de asistencia para identificar dispositivos USB y accesorios USB, y comunicarse con ellos. Las aplicaciones pueden adquirir una instancia de UsbManager y, luego, consultar la lista de dispositivos o accesorios adjuntos y, luego, comunicarse con ellos o administrarlos. UsbManager también declara las acciones de intent que transmite el sistema para anunciar cuando se conecta o desconecta un dispositivo o accesorio USB.

Otras clases incluyen:

  • UsbDevice: Es una clase que representa el hardware externo conectado como un dispositivo USB (con el dispositivo Android que actúa como host).
  • UsbAccessory, que representa el hardware externo conectado como el host USB (con el dispositivo con Android que actúa como un dispositivo USB)
  • UsbInterface y UsbEndpoint, que proporcionan acceso a extremos y interfaces USB estándar para un dispositivo.
  • UsbDeviceConnection y UsbRequest para enviar y recibir datos, y controlar mensajes hacia o desde un dispositivo USB, de forma síncrona y asíncrona.
  • UsbConstants, que proporciona constantes para declarar tipos de extremos, clases de dispositivos, etcétera.

Ten en cuenta que, aunque la pila USB está integrada en la plataforma, los fabricantes determinan la compatibilidad real con los modos de host USB y de accesorio abierto en dispositivos específicos. En particular, el modo de host se basa en el hardware de controlador USB adecuado del dispositivo con Android.

Además, los desarrolladores pueden solicitar filtros en Google Play para que sus aplicaciones no estén disponibles para los usuarios cuyos dispositivos no proporcionen la compatibilidad con USB adecuada. Para solicitar el filtrado, agrega uno de los siguientes elementos o ambos al manifiesto de la aplicación, según corresponda:

  • Si la aplicación solo debería ser visible para los dispositivos que admiten el modo de host USB (conexión de dispositivos USB), declara este elemento:

    <uses-feature android:name="android.hardware.usb.host" android:required="true">

  • Si la aplicación solo debería ser visible para los dispositivos que admiten accesorios USB (conexión de hosts USB), declara este elemento:

    <uses-feature android:name="android.hardware.usb.accessory" android:required="true">

Para obtener información completa sobre cómo desarrollar aplicaciones que interactúen con accesorios USB, consulta la documentación para desarrolladores.

Para ver las aplicaciones de ejemplo que usan la API del host USB, consulta Prueba ADB y Selector de misiles

API de MTP/PTP

Android 3.1 expone una nueva API de MTP que permite a las aplicaciones interactuar directamente con cámaras conectadas y otros dispositivos PTP. La nueva API permite que una aplicación reciba fácilmente notificaciones cuando se conectan y quitan dispositivos, administra archivos y almacenamiento en esos dispositivos, y transfiere archivos y metadatos desde y hacia ellos. La API de MTP implementa el subconjunto de PTP (Protocolo de transferencia de imágenes) de la especificación de MTP (Protocolo de transferencia de medios).

La API de MTP está disponible en el paquete android.mtp y proporciona las siguientes clases:

  • El MtpDevice encapsula un dispositivo MTP que se conecta a través del bus USB del host. Una aplicación puede crear una instancia de un objeto de este tipo y usar sus métodos para obtener información sobre el dispositivo y los objetos almacenados en él, además de abrir la conexión y transferir datos. Estos son algunos de los métodos:
    • getObjectHandles() muestra una lista de controladores para todos los objetos del dispositivo que coinciden con un formato y un elemento superior especificados. Para obtener información sobre un objeto, una aplicación puede pasar un controlador a getObjectInfo().
    • importFile() permite que una aplicación copie datos de un objeto a un archivo del almacenamiento externo. Esta llamada puede bloquearse por un tiempo arbitrario según el tamaño de los datos y la velocidad de los dispositivos, por lo que se debe realizar desde un subproceso espeado.
    • open() permite que una aplicación abra un dispositivo MTP/PTP conectado.
    • getThumbnail() muestra la miniatura del objeto como un array de bytes.
  • MtpStorageInfo contiene información sobre una unidad de almacenamiento en un dispositivo MTP, que corresponde al conjunto de datos StorageInfo que se describe en la sección 5.2.2 de la especificación MTP. Los métodos de la clase permiten que una aplicación obtenga la cadena de descripción de una unidad de almacenamiento, el espacio libre, la capacidad máxima de almacenamiento, el ID de almacenamiento y el identificador de volumen.
  • MtpDeviceInfo contiene información sobre un dispositivo MTP correspondiente al conjunto de datos de DeviceInfo que se describe en la sección 5.1.1 de la especificación de MTP. Los métodos de la clase permiten que las aplicaciones obtengan el fabricante, el modelo, el número de serie y la versión de un dispositivo.
  • MtpObjectInfo contiene información sobre un objeto almacenado en un dispositivo MTP, que corresponde al conjunto de datos ObjectInfo descrito en la sección 5.3.1 de la especificación MTP. Los métodos de la clase permiten que las aplicaciones obtengan el tamaño, el formato de datos, el tipo de asociación, la fecha de creación y la información de la miniatura de un objeto.
  • MtpConstants proporciona constantes para declarar códigos de formato de archivo MTP, el tipo de asociación y el estado de protección.

Compatibilidad con nuevos dispositivos de entrada y eventos de movimiento

Android 3.1 extiende el subsistema de entrada para admitir nuevos dispositivos de entrada y nuevos tipos de eventos de movimiento en todas las vistas y ventanas. Los desarrolladores pueden aprovechar estas capacidades para permitir que los usuarios interactúen con sus aplicaciones mediante mouse, bolas de seguimiento, joysticks, controles de juegos y otros dispositivos, además de teclados y pantallas táctiles.

Para controlar la entrada del mouse, la rueda de desplazamiento y la bola de seguimiento, la plataforma admite dos nuevas acciones de eventos de movimiento:

  • ACTION_SCROLL, que describe la ubicación del puntero en la que se realiza un movimiento de desplazamiento no táctil, como el de la rueda del mouse En el MotionEvent, el valor de los ejes AXIS_HSCROLL y AXIS_VSCROLL especifica el movimiento de desplazamiento relativo.
  • ACTION_HOVER_MOVE, informa la posición actual del mouse cuando no se presiona ningún botón, así como los puntos intermedios desde el último evento HOVER_MOVE. Aún no se admiten las notificaciones de entrada y salida para colocar el cursor sobre un elemento.

Para admitir joysticks y controles de juegos, la clase InputDevice incluye estas fuentes de dispositivos de entrada nuevas:

Para describir los eventos de movimiento de estas fuentes nuevas, así como los de mouse y bolas de seguimiento, la plataforma ahora define códigos de eje en MotionEvent, de manera similar a como define códigos de teclas en KeyEvent. Los nuevos códigos de eje para joysticks y controles de juegos incluyen AXIS_HAT_X, AXIS_HAT_Y, AXIS_RTRIGGER, AXIS_ORIENTATION, AXIS_THROTTLE y muchos más. Los ejes MotionEvent existentes se representan con AXIS_X, AXIS_Y, AXIS_PRESSURE, AXIS_SIZE, AXIS_TOUCH_MAJOR, AXIS_TOUCH_MINOR, AXIS_TOOL_MAJOR, AXIS_TOOL_MINOR y AXIS_ORIENTATION.

Además, MotionEvent define una cantidad de códigos de eje genéricos que se usan cuando el framework no sabe cómo asignar un eje en particular. Los dispositivos específicos pueden usar los códigos de eje genéricos para pasar datos de movimiento personalizados a las aplicaciones. Para obtener una lista completa de los ejes y las interpretaciones previstas, consulta la documentación de la clase MotionEvent.

La plataforma proporciona eventos de movimiento a las aplicaciones por lotes, por lo que un solo evento puede contener una posición actual y varios movimientos históricos. Las aplicaciones deben usar getHistorySize() para obtener la cantidad de muestras históricas y, luego, recuperar y procesar todas las muestras históricas en orden con getHistoricalAxisValue(). Después de eso, las aplicaciones deben procesar la muestra actual con getAxisValue().

Algunos ejes se pueden recuperar con métodos de acceso especiales. Por ejemplo, en lugar de llamar a getAxisValue(), las aplicaciones pueden llamar a getX(). Entre los ejes que tienen descriptores de acceso integrados, se incluyen AXIS_X, AXIS_Y, AXIS_PRESSURE, AXIS_SIZE, AXIS_TOUCH_MAJOR, AXIS_TOUCH_MINOR, AXIS_TOOL_MAJOR, AXIS_TOOL_MINOR y AXIS_ORIENTATION.

Cada dispositivo de entrada tiene un ID único asignado por el sistema y también puede proporcionar varias fuentes. Cuando un dispositivo proporciona varias fuentes, más de una puede proporcionar datos de eje usando el mismo eje. Por ejemplo, un evento táctil que proviene de la fuente táctil usa el eje X para los datos de posición de la pantalla, mientras que un evento del joystick que proviene de la fuente del joystick usará el eje X para la posición del stick. Por este motivo, es importante que las aplicaciones interpreten los valores de los ejes según la fuente desde la que se originan. Cuando se controla un evento de movimiento, las aplicaciones deben usar métodos de la clase InputDevice para determinar los ejes que admite un dispositivo o una fuente. Específicamente, las aplicaciones pueden usar getMotionRanges() para consultar todos los ejes de un dispositivo o todos los ejes de una fuente determinada del dispositivo. En ambos casos, la información de rango para los ejes que se muestra en el objeto InputDevice.MotionRange especifica el origen de cada valor de eje.

Por último, como los eventos de movimiento de los joysticks, los controles de juegos, los mouse y las bolas de seguimiento no son eventos táctiles, la plataforma agrega un nuevo método de devolución de llamada para pasarlos a un View como eventos de movimiento “genéricos”. Específicamente, informa los eventos de movimiento no táctiles a View a través de una llamada a onGenericMotionEvent(), en lugar de onTouchEvent().

La plataforma despacha los eventos de movimiento genéricos de manera diferente, según la clase de fuente del evento. Los eventos SOURCE_CLASS_POINTER van a View debajo del puntero, de manera similar al funcionamiento de los eventos táctiles. Todos los demás van a la View seleccionada actualmente. Por ejemplo, esto significa que un View debe enfocarse para recibir eventos del joystick. Si es necesario, las aplicaciones pueden controlar estos eventos en el nivel de la actividad o el diálogo implementando onGenericMotionEvent() allí.

Para ver una aplicación de ejemplo que usa eventos de movimiento del joystick, consulta GameControllerInput y GameView.

API de RTP

Android 3.1 expone una API a su pila de RTP (protocolo de transporte en tiempo real) integrada, que las aplicaciones pueden usar para administrar la transmisión de datos interactiva o a pedido. En particular, las apps que proporcionan VoIP, envío para hablar, conferencias y transmisión de audio pueden usar la API para iniciar sesiones y transmitir o recibir transmisiones de datos por medio de cualquier red disponible.

La API de RTP está disponible en el paquete android.net.rtp. Estas son algunas de las clases:

  • RtpStream, la clase base de transmisiones que envían y reciben paquetes de red con cargas útiles de contenido multimedia a través de RTP.
  • AudioStream, una subclase de RtpStream que lleva cargas útiles de audio a través de RTP
  • AudioGroup, un concentrador de audio local para administrar y combinar la bocina del dispositivo, el micrófono y AudioStream.
  • AudioCodec, que contiene una colección de códecs que defines para un AudioStream.

Para admitir conferencias de audio y usos similares, una aplicación crea una instancia de dos clases como extremos para la transmisión:

  • AudioStream especifica un extremo remoto y consta de una asignación de red y un AudioCodec configurado.
  • AudioGroup representa el extremo local de uno o más objetos AudioStream. El AudioGroup mezcla todas las AudioStream y, de manera opcional, interactúa con la bocina del dispositivo y el micrófono al mismo tiempo.

El uso más sencillo implica un solo extremo remoto y un extremo local. Para usos más complejos, consulta las limitaciones que se describen para AudioGroup.

Para usar la API de RTP, las aplicaciones deben solicitar el permiso del usuario declarando <uses-permission android:name="android.permission.INTERNET"> en sus archivos de manifiesto. Para obtener el micrófono del dispositivo, también se requiere el permiso <uses-permission android:name="android.permission.RECORD_AUDIO">.

Widgets de apps de tamaño variable

A partir de Android 3.1, los desarrolladores pueden hacer que se pueda cambiar el tamaño de sus widgets de la pantalla principal, ya sea horizontal, verticalmente o en ambos ejes. Los usuarios mantienen presionado un widget para mostrar sus controladores de cambio de tamaño y, luego, arrastran los controladores horizontal o vertical para cambiar el tamaño en la cuadrícula de diseño.

Los desarrolladores pueden hacer que cualquier widget de la pantalla principal pueda cambiar de tamaño. Para ello, deben definir un atributo resizeMode en los metadatos AppWidgetProviderInfo del widget. Los valores para el atributo resizeMode incluyen "horizontal", "vertical" y "ninguno". Para declarar un widget como que se puede cambiar de tamaño horizontal y verticalmente, proporciona el valor "horizontal|vertical".

Por ejemplo: 

<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
    android:minWidth="294dp"
    android:minHeight="72dp"
    android:updatePeriodMillis="86400000"
    android:previewImage="@drawable/preview"
    android:initialLayout="@layout/example_appwidget"
    android:configure="com.example.android.ExampleAppWidgetConfigure"
    android:resizeMode="horizontal|vertical" >
</appwidget-provider>

Para obtener más información sobre los widgets de la pantalla principal, consulta la documentación Widgets de la app.

Framework de animación

  • Nueva clase ViewPropertyAnimator
    • Una nueva clase ViewPropertyAnimator proporciona una forma conveniente para que los desarrolladores animen propiedades seleccionadas en objetos View. La clase automatiza y optimiza la animación de las propiedades y facilita la administración de varias animaciones simultáneas en un objeto View.

      El uso de ViewPropertyAnimator es sencillo. Para animar propiedades para un View, llama a animate() para construir un objeto ViewPropertyAnimator para esa View. Usa los métodos de ViewPropertyAnimator para especificar qué propiedad animar y cómo hacerlo. Por ejemplo, para atenuar View a transparente, llama a alpha(0);. El objeto ViewPropertyAnimator controla los detalles de configuración de la clase Animator subyacente, su inicio y, luego, la renderización de la animación.

  • Color de fondo de la animación
    • Los nuevos métodos getBackgroundColor() y setBackgroundColor(int) te permiten obtener y establecer el color de fondo detrás de las animaciones, solo para animaciones de ventanas. Actualmente, el fondo debe ser negro, con cualquier nivel alfa deseado.
  • Se obtiene una fracción animada de ViewAnimator
    • Un nuevo método getAnimatedFraction() te permite obtener la fracción de animación actual (la fracción transcurrida/interpolada que se usó en la actualización de fotogramas más reciente) a partir de un ValueAnimator.

Framework de IU

  • Renderización forzada de una capa
    • Un nuevo método buildLayer() permite que una aplicación fuerce la creación de una capa de View y la renderización de View en ella de inmediato. Por ejemplo, una aplicación podría usar este método para renderizar una View en su capa antes de iniciar una animación. Si la vista es compleja, renderizarla en la capa antes de comenzar la animación evitará la omisión de fotogramas.
  • Distancia de la cámara
    • Las aplicaciones pueden usar un nuevo método setCameraDistance(float) para establecer la distancia entre la cámara y un elemento View. Esto brinda a las aplicaciones un control mejorado sobre las transformaciones 3D de la vista, como las rotaciones.
  • Obtén una vista de calendario con un selector de fecha
  • Obtén devoluciones de llamada cuando se desconectan las vistas
  • Objeto de escucha de ruta de navegación de fragmentos, nueva firma onInflate()
  • Mostrar el resultado de la búsqueda en una pestaña nueva
    • Una clave de datos EXTRA_NEW_SEARCH para intents ACTION_WEB_SEARCH te permite abrir una búsqueda en una pestaña del navegador nueva, en lugar de en una existente.
  • Cursor de texto del elemento de diseño
    • Ahora puedes especificar un elemento de diseño para usar como cursor de texto usando el nuevo atributo de recurso textCursorDrawable.
  • Configuración del elemento secundario que se muestra en las vistas remotas
  • Teclas genéricas para controles de juegos y otros dispositivos de entrada
    • KeyEvent agrega un rango de códigos de teclas genéricos para adaptarse a los botones del control de juegos. La clase también agrega isGamepadButton(int) y varios otros métodos auxiliares para trabajar con códigos de teclas.

Gráficos

  • Asistentes para administrar mapas de bits
    • setHasAlpha(boolean) permite que una app indique que se sabe que todos los píxeles de un mapa de bits son opacos (falso) o que algunos de los píxeles pueden contener valores alfa no opacos (verdadero). Ten en cuenta que, para algunas configuraciones (como RGB_565), esta llamada se ignora, ya que no admite valores alfa por píxel. Esto se proporciona como una sugerencia de dibujo, ya que, en algunos casos, un mapa de bits que se sabe como opaco puede emplear un caso de dibujo más rápido que uno que puede tener valores alfa no opacos por píxel.
    • getByteCount() obtiene el tamaño de un mapa de bits en bytes.
    • getGenerationId() permite que una aplicación detecte si se modificó un mapa de bits, por ejemplo, para almacenarlo en caché.
    • sameAs(android.graphics.Bitmap) determina si un mapa de bits determinado difiere del mapa de bits actual en dimensión, configuración o datos de píxeles.
  • Cómo configurar la ubicación y la rotación de la cámara

Red

  • Bloqueo de Wi-Fi de alto rendimiento
    • Un nuevo bloqueo de Wi-Fi de alto rendimiento permite que las aplicaciones mantengan conexiones Wi-Fi de alto rendimiento incluso cuando la pantalla del dispositivo está apagada. Las aplicaciones que transmiten música, video o voz durante períodos prolongados pueden adquirir el bloqueo de Wi-Fi de alto rendimiento para garantizar el rendimiento de la transmisión, incluso cuando la pantalla está apagada. Dado que consume más energía, las aplicaciones deben adquirir la Wi-Fi de alto rendimiento cuando se necesita una conexión de alto rendimiento.

      Para crear un bloqueo de alto rendimiento, pasa WIFI_MODE_FULL_HIGH_PERF como el modo bloqueado en una llamada a createWifiLock().

  • Más estadísticas de tráfico
    • Las aplicaciones ahora pueden acceder a las estadísticas sobre más tipos de uso de red con métodos nuevos en TrafficStats. Las aplicaciones pueden usar los métodos para obtener estadísticas UDP, el recuento de paquetes, la transmisión/recepción de bytes de carga útil de TCP y los segmentos para un UID determinado.
  • Nombre de usuario de autenticación SIP
    • Las aplicaciones ahora pueden obtener y establecer el nombre de usuario de autenticación de SIP de un perfil mediante los nuevos métodos getAuthUserName() y setAuthUserName().

Administrador de descargas

  • Control de las descargas completadas
    • Las aplicaciones ahora pueden iniciar descargas que notifican a los usuarios solo cuando finalizan. Para iniciar este tipo de descarga, las aplicaciones pasan VISIBILITY_VISIBLE_NOTIFY_ONLY_COMPLETION en el método setNotificationVisibility() de un objeto de solicitud.
    • Un método nuevo, addCompletedDownload(), permite que una aplicación agregue un archivo a la base de datos de descargas para que la aplicación de descargas pueda administrarlo.
  • Mostrar las descargas ordenadas por tamaño

Marco de IME

  • Cómo obtener la clave de valor adicional de un método de entrada

Contenido multimedia

  • Nuevos formatos de transmisión de audio
    • El framework multimedia agrega compatibilidad integrada con contenido ADTS AAC sin procesar para mejorar la transmisión de audio, así como compatibilidad con audio FLAC para obtener contenido de audio comprimido de la más alta calidad (sin pérdidas). Consulta el documento Formatos de medios compatibles para obtener más información.

Controles de inicio en aplicaciones detenidas

A partir de Android 3.1, el administrador de paquetes del sistema realiza un seguimiento de las aplicaciones que están detenidas y proporciona un medio para controlar su inicio desde procesos en segundo plano y otras aplicaciones.

Ten en cuenta que el estado de detención de una aplicación no es lo mismo que el estado de detención de una actividad. El sistema administra esos dos estados detenidos por separado.

La plataforma define dos marcas de intent nuevas que permiten a un remitente especificar si el intent debe poder activar componentes en una aplicación detenida.

Cuando ninguna de estas marcas o ambas se definen en un intent, el comportamiento predeterminado es incluir los filtros de las aplicaciones detenidas en la lista de objetivos potenciales.

Ten en cuenta que el sistema agrega FLAG_EXCLUDE_STOPPED_PACKAGES a todos los intents de transmisión. Lo hace para evitar que las transmisiones de servicios en segundo plano inicien componentes de aplicaciones detenidas de manera involuntaria o innecesaria. Una aplicación o un servicio en segundo plano pueden anular este comportamiento agregando la marca FLAG_INCLUDE_STOPPED_PACKAGES a los intents de transmisión que deberían poder activar aplicaciones detenidas.

Las aplicaciones se encuentran detenidas cuando se instalan por primera vez, pero aún no se inician, y cuando el usuario las detiene manualmente (en Administrar aplicaciones).

Notificación del primer lanzamiento y actualización de la aplicación

La plataforma agrega una notificación mejorada del primer lanzamiento de la aplicación y actualizaciones mediante dos nuevas acciones de intent:

  • ACTION_PACKAGE_FIRST_LAUNCH: Se envía al paquete del instalador de una aplicación cuando esta se inicia por primera vez (es decir, la primera vez que sale de un estado de detención). Los datos contienen el nombre del paquete.
  • ACTION_MY_PACKAGE_REPLACED: Notifica a una aplicación que se actualizó y que se instaló una versión nueva en lugar de una existente. Este mensaje solo se envía a la aplicación que se reemplazó. No contiene datos adicionales. Si quieres recibirla, declara un filtro de intents para esta acción. Puedes usar el intent para activar el código que ayuda a que la aplicación vuelva a funcionar correctamente después de una actualización.

    Este intent se envía directamente a la aplicación, pero solo si esta se actualizó mientras estaba en estado iniciado (no en estado detenido).

Utilidades principales

  • Caché LRU
    • Una nueva clase LruCache permite que tus aplicaciones se beneficien del almacenamiento en caché eficiente. Las aplicaciones pueden usar la clase para reducir el tiempo dedicado a procesar o descargar datos de la red, a la vez que mantienen un uso de memoria razonable para los datos almacenados en caché.LruCache es una caché que contiene referencias importantes a una cantidad limitada de valores. Cada vez que se accede a un valor, este pasa al principio de una cola. Cuando se agrega un valor a una caché completa, el valor al final de esa cola se expulsa y puede ser apto para la recolección de elementos no utilizados.
  • Descriptor de archivo como int

WebKit

  • Cookies de esquema de archivos
    • CookieManager ahora admite cookies que usan el esquema de URI file:. Puedes usar setAcceptFileSchemeCookies() para habilitar o inhabilitar la compatibilidad con las cookies de esquema de archivos antes de construir una instancia de WebView o CookieManager. En una instancia de CookieManager, puedes verificar si las cookies de esquema de archivos están habilitadas llamando a allowFileSchemeCookies().
  • Notificación de solicitud de acceso
    • Para admitir las funciones de acceso automático del navegador que se introdujeron en Android 3.0, el nuevo método onReceivedLoginRequest() notifica a la aplicación host que se procesó una solicitud de acceso automático para el usuario.
  • Se quitaron interfaces y clases
    • Se quitaron varias interfaces y clases de la API pública, después de que el estado quedara obsoleto. Consulta el Informe de diferencias de las APIs para obtener más información.

Navegador

La aplicación de navegador agrega las siguientes funciones para admitir aplicaciones web:

  • Compatibilidad con la reproducción intercalada de videos incorporados en la etiqueta <video> de HTML5. La reproducción es acelerada por hardware siempre que sea posible.
  • Admite capas de elementos de posición fija en todos los sitios (dispositivos móviles y computadoras de escritorio).

Nuevas constantes de funciones

La plataforma agrega nuevas constantes de funciones de hardware que los desarrolladores pueden declarar en los manifiestos de sus aplicaciones para informar a entidades externas, como Google Play, el requisito de la aplicación de nuevas capacidades de hardware compatibles con esta versión de la plataforma. Los desarrolladores declaran estas y otras constantes de funciones en los elementos del manifiesto <uses-feature>.

Google Play filtra las aplicaciones según las funciones declaradas en los elementos del manifiesto de <uses-feature>. Para obtener más información sobre la declaración de funciones en el manifiesto de una aplicación, lee Filtros de Google Play.

Informe de diferencias de las APIs

Para obtener una vista detallada de todos los cambios de la API en Android 3.1 (nivel de API 12), consulta el Informe de diferencias de las APIs.

Nivel de API

La plataforma Android 3.1 ofrece una versión actualizada de la API de framework. A la API de Android 3.1 se le asigna un identificador de número entero, 12, que se almacena en el propio sistema. Este identificador, llamado "nivel de API", permite que el sistema determine correctamente si una aplicación es compatible con él antes de instalarla.

Para usar las APIs de Android 3.1 en tu aplicación, deberás compilarla en la biblioteca de Android que se proporciona en la plataforma de SDK de Android 3.1. Según tus necesidades, es posible que también debas agregar un atributo android:minSdkVersion="12" al elemento <uses-sdk> en el manifiesto de la aplicación.

Para obtener más información, consulta ¿Qué es el nivel de API?