API de Android 3.1

Nivel de API: 12

Para los desarrolladores, la plataforma de Android 3.1 (HONEYCOMB_MR1) está disponible como un componente descargable del SDK de Android. La plataforma descargable incluye una imagen del sistema y una biblioteca de Android, así como 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 un componente descargable del SDK de Android. La plataforma descargable incluye una imagen del sistema y una biblioteca de Android, así como un conjunto de máscaras de emulador y mucho más. Para comenzar a desarrollar o probar Android 3.1, usa Android SDK Manager 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 de Android 3.1, como las nuevas funciones 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 interacciones del host USB y del dispositivo. Con las APIs, los desarrolladores pueden crear aplicaciones capaces de descubrir, comunicarse y administrar varios 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 un conjunto de hardware conectado que depende del dispositivo Android para funcionar como host. Por ejemplo, la mayoría de los dispositivos de entrada, el mouse y los joysticks son dispositivos USB, al igual que muchas cámaras, concentradores, etcétera.
  • Un accesorio USB es un elemento de hardware conectado que tiene un controlador de host USB, proporciona energía y está diseñado para comunicarse con dispositivos Android a través de USB. Existe una variedad de periféricos que se pueden conectar 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 intent 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 auxiliares 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 conectados 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.

Entre otras clases, se incluyen las siguientes:

  • UsbDevice: Es una clase que representa el hardware externo conectado como un dispositivo USB (el dispositivo Android actúa como host).
  • UsbAccessory, que representa el hardware externo conectado como el host USB (el dispositivo con Android 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 apropiado 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 adecuada con USB. Para solicitar el filtrado, agrega uno o ambos de los siguientes elementos al manifiesto de la aplicación, según corresponda:

  • Si la aplicación solo debería ser visible para 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 dispositivos que admiten accesorios USB (conexión de hosts USB), declara este elemento:

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

Si quieres obtener información completa para desarrollar aplicaciones que interactúen con accesorios USB, consulta la documentación para desarrolladores.

Para ver las aplicaciones de muestra 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 que las aplicaciones interactúen directamente con las cámaras conectadas y otros dispositivos PTP. La nueva API permite que una aplicación reciba notificaciones cuando se conectan y quitan dispositivos, administra archivos y almacenamiento en esos dispositivos con facilidad y transfiere archivos y metadatos desde y hacia ellos. La API de MTP implementa el subconjunto 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 host USB. 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 los datos de un objeto en un archivo del almacenamiento externo. Esta llamada se puede bloquear por un tiempo arbitrario según el tamaño de los datos y la velocidad de los dispositivos, por lo que debe realizarse desde un subproceso independiente.
    • 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 de 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 que corresponde 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 de ObjectInfo que se describe en la sección 5.3.1 de la especificación de MTP. Los métodos de la clase permiten que las aplicaciones obtengan el tamaño, el formato de los 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 realizó un movimiento de desplazamiento no táctil, como el de la rueda de desplazamiento 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 eventos de movimiento de estas fuentes nuevas, así como de mouse y bolas de seguimiento, la plataforma ahora define códigos de ejes en MotionEvent, de manera similar a como define códigos de tecla en KeyEvent. Los nuevos códigos de ejes 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. Algunos dispositivos específicos pueden usar los códigos genéricos del eje para pasar datos de movimiento personalizados a las aplicaciones. Para obtener una lista completa de los ejes y sus interpretaciones previstas, consulta la documentación de la clase MotionEvent.

La plataforma proporciona eventos de movimiento a las aplicaciones en 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 de una fuente determinada del dispositivo. En ambos casos, la información del rango de los ejes que se muestran 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áctil a los View a través de una llamada a onGenericMotionEvent(), en lugar de a 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 enfocada en este momento. Por ejemplo, esto significa que un View debe enfocarse para recibir eventos del joystick. Si es necesario, las aplicaciones pueden controlar estos eventos a nivel de Activity o Dialog si implementan 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, enviar para hablar, conferencias y transmisión de audio pueden usar la API a fin de iniciar sesiones y transmitir o recibir transmisiones de datos a través de cualquier red disponible.

La API de RTP está disponible en el paquete android.net.rtp. Las clases incluyen lo siguiente:

  • RtpStream es 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 mezclar 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 de la transmisión:

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

El uso más simple 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 los 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 los widgets de la pantalla principal en sentido horizontal o vertical, o en ambos ejes. Los usuarios mantienen presionado un widget para mostrar sus controladores de cambio de tamaño y, luego, arrastran los controladores horizontales o verticales 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 si definen un atributo resizeMode en los metadatos AppWidgetProviderInfo del widget. Los valores para el atributo resizeMode incluyen "horizontal", "vertical" y "none". Para declarar un widget como horizontal y vertical, 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 apps.

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.

      Usar ViewPropertyAnimator es sencillo. Para animar propiedades de un View, llama a animate() a fin de construir un objeto ViewPropertyAnimator para ese View. Usa los métodos en ViewPropertyAnimator para especificar qué propiedad se debe animar y cómo hacerlo. Por ejemplo, para atenuar View a transparente, llama a alpha(0);. El objeto ViewPropertyAnimator controla los detalles de la 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.
  • Obtener la 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 más reciente de fotogramas) 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 View se renderice en ella de inmediato. Por ejemplo, una aplicación podría usar este método para renderizar una vista 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 una View. Esto les brinda a las aplicaciones un control mejorado de las transformaciones 3D de la vista, como las rotaciones.
  • Obtén una vista de calendario desde un selector de fecha
  • Obtén devoluciones de llamada cuando se desconectan las vistas.
  • Objeto de escucha de la 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 con 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. También agrega isGamepadButton(int) y muchos otros métodos auxiliares para trabajar con códigos de teclas.

Gráficos

  • Ayuda 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 píxeles pueden contener valores alfa no opacos (verdadero). Ten en cuenta que, para algunas configuraciones (como RGB_565), se ignora esta llamada, 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 que es opaco puede requerir 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 el almacenamiento en caché.
    • sameAs(android.graphics.Bitmap) determina si un mapa de bits determinado difiere del mapa de bits actual en cuanto a dimensión, configuración o datos de píxeles.
  • Configuración de 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, videos 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. Como consume más energía, las aplicaciones deben adquirir el Wi-Fi de alto rendimiento cuando hay una conexión activa 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
    • Ahora, las aplicaciones pueden acceder a 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, recuento de paquetes, bytes de carga útil de transmisión/recepción de TCP y segmentos para un UID determinado.
  • Nombre de usuario de autenticación SIP
    • Ahora las aplicaciones pueden obtener y configurar 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
  • Mostrar las descargas ordenadas por tamaño

Framework del 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, lo que brinda contenido de audio comprimido de mayor 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 se encuentran 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 detenido 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 se debe permitir que el intent active componentes en una aplicación detenida.

Cuando ninguna de estas marcas o ambas se definen en un intent, el comportamiento predeterminado es incluir filtros de 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, de manera inadvertida o innecesaria, componentes de aplicaciones detenidas. Una aplicación o un servicio en segundo plano puede anular este comportamiento agregando la marca FLAG_INCLUDE_STOPPED_PACKAGES a los intents de transmisión que deberían tener permitido activar aplicaciones detenidas.

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

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

La plataforma agrega una notificación mejorada del primer lanzamiento de la aplicación y se actualiza a través de 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 detenido). Los datos contienen el nombre del paquete.
  • ACTION_MY_PACKAGE_REPLACED: Notifica a una aplicación que se actualizó, con una versión nueva instalada 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 la aplicación se actualizó mientras estaba iniciada (no en estado detenida).

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, al mismo tiempo que mantienen un espacio 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 se mueve al encabezado de una cola. Cuando se agrega un valor a una caché completa, el valor al final de esa cola se expulsa y es posible que sea apto para la recolección de elementos no utilizados.
  • Descriptor de archivo como int

WebKit

  • Cookies de esquemas de archivos
    • El CookieManager ahora admite cookies que usan el esquema de URI file:. Puedes usar setAcceptFileSchemeCookies() para habilitar o inhabilitar la compatibilidad con cookies de esquemas de archivos antes de construir una instancia de WebView o CookieManager. En una instancia CookieManager, puedes verificar si las cookies de esquemas 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, luego de que antes quedaran en estado obsoleto. Consulta el Informe de diferencias de las APIs para obtener más información.

Navegador

La aplicación 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 se acelera mediante hardware siempre que sea posible.
  • Compatibilidad con capas para 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, los requisitos 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 <uses-feature>. Para obtener más información sobre cómo declarar 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 API.

Nivel de API

La plataforma de Android 3.1 entrega 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, denominado "nivel de API", permite que el sistema determine correctamente si una aplicación es compatible con él antes de instalarla.

Para usar las API que se introdujeron en Android 3.1 en tu aplicación, deberás compilarla con la biblioteca de Android que se proporciona en la plataforma del 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?