API de Android 3.1

Nivel de API: 12

Para los desarrolladores, la plataforma Android 3.1 (HONEYCOMB_MR1) está disponible como un componente descargable para el SDK de Android. La plataforma descargable incluye una biblioteca de Android y una imagen del sistema, además de 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 biblioteca de Android y una imagen del sistema, además de un conjunto de máscaras de emulador y mucho más. Para comenzar a desarrollar o realizar pruebas en Android 3.1, usa el 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 del framework desde la versión anterior.

APIs de USB

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

La pila y las APIs distinguen dos tipos básicos de hardware USB, según 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 conectada que depende del dispositivo con Android para funcionar como host. Por ejemplo, la mayoría de los dispositivos de entrada, los mouses y los joysticks son dispositivos USB, al igual que muchas cámaras, concentradores, etcétera.
  • Un accesorio USB es una pieza de hardware conectada que tiene un controlador de host USB, proporciona energía y está diseñada para comunicarse con dispositivos con tecnología Android a través de USB. Se puede conectar una variedad de periféricos como accesorios, desde controladores de robótica hasta equipos musicales, bicicletas de ejercicio 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 conectan o desconectan, así como interfaces, extremos y modos de transferencia estándar (control, masivo y de interrupción).

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 para comunicarse con ellos o administrarlos. UsbManager también declara acciones de intents que el sistema transmite para anunciar cuando se conecta o desconecta un dispositivo o accesorio USB.

Otras clases incluyen las siguientes:

  • UsbDevice, una clase que representa el hardware externo conectado como un dispositivo USB (con el dispositivo con tecnología Android como host)
  • UsbAccessory, que representa el hardware externo conectado como host USB (con el dispositivo con Android que actúa como dispositivo USB)
  • UsbInterface y UsbEndpoint, que proporcionan acceso a interfaces y extremos USB estándar para un dispositivo
  • UsbDeviceConnection y UsbRequest, para enviar y recibir datos y mensajes de control desde o hacia 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, si bien la pila de USB está integrada en la plataforma, la compatibilidad real con los modos de host USB y de accesorio abierto en dispositivos específicos la determinan sus fabricantes. En particular, el modo de host se basa en el hardware del controlador USB adecuado en el dispositivo con Android.

Además, los desarrolladores pueden solicitar el filtrado en Google Play, de modo 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 o ambos elementos que se indican a continuación al manifiesto de la aplicación, según corresponda:

  • Si la aplicación solo debe 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 debe 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 aplicaciones de ejemplo que usan la API de host USB, consulta ADB Test y Missile Launcher.

API de MTP/PTP

Android 3.1 expone una nueva API de MTP que permite que las aplicaciones interactúen directamente con cámaras conectadas y otros dispositivos PTP. La nueva API facilita que una aplicación reciba notificaciones cuando se conectan y desconectan dispositivos, administre archivos y almacenamiento en esos dispositivos, y transfiera archivos y metadatos hacia y desde 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 contenido multimedia).

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

  • MtpDevice encapsula un dispositivo MTP que está conectado a través del bus del host USB. Una aplicación puede crear una instancia de un objeto de este tipo y, luego, usar sus métodos para obtener información sobre el dispositivo y los objetos almacenados en él, así como abrir la conexión y transferir datos. Estos son algunos de los métodos:
    • getObjectHandles() devuelve 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 en un archivo del almacenamiento externo. Esta llamada puede bloquearse durante un período 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 o PTP conectado.
    • getThumbnail() devuelve 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 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 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 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, tipo de asociación y 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 funciones para permitir que los usuarios interactúen con sus aplicaciones usando 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 acciones de eventos de movimiento nuevas:

  • ACTION_SCROLL, que describe la ubicación del puntero en la que se produjo un movimiento de desplazamiento sin contacto, como el de la rueda del mouse. En 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 cualquier punto intermedio desde el último evento HOVER_MOVE. Aún no se admiten las notificaciones de entrada y salida de desplazamiento.

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

Para describir los eventos de movimiento de estas nuevas fuentes, así como los de los ratones y las bolas de seguimiento, la plataforma ahora define códigos de eje en MotionEvent, de manera similar a como define los 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 otros. 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 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(). Los ejes que tienen descriptores de acceso integrados 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 con 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 de joystick que proviene de la fuente de joystick usará el eje X para la posición de la palanca. Por este motivo, es importante que las aplicaciones interpreten los valores de los ejes según la fuente de la que provienen. Cuando se controla un evento de movimiento, las aplicaciones deben usar métodos en 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 del rango de los ejes que se devuelve en el objeto InputDevice.MotionRange especifica la fuente de cada valor de eje.

Por último, dado que los eventos de movimiento de joysticks, controles de juegos, mouses y 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 sin contacto a los View a través de una llamada a onGenericMotionEvent(), en lugar de a onTouchEvent().

La plataforma envía eventos de movimiento genéricos de manera diferente, según la clase de fuente del evento. Los eventos SOURCE_CLASS_POINTER van al View debajo del puntero, de manera similar a como funcionan los eventos táctiles. Todas las demás se dirigen al View que está enfocado en ese momento. Por ejemplo, esto significa que un View debe tomar el foco para recibir eventos de joystick. Si es necesario, las aplicaciones pueden controlar estos eventos a nivel de Activity o Dialog implementando onGenericMotionEvent() allí.

Para ver una aplicación de ejemplo que use eventos de movimiento de 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, pulsar para hablar, conferencias y transmisión de audio pueden usar la API para 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, 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 transporta cargas útiles de audio a través de RTP
  • AudioGroup, un concentrador de audio local para administrar y mezclar la bocina, el micrófono y el AudioStream del dispositivo
  • 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:

El uso más simple implica un solo extremo remoto y un extremo local. Para usos más complejos, consulta las limitaciones descritas para AudioGroup.

Para usar la API de RTP, las aplicaciones deben solicitar permiso al usuario declarando <uses-permission android:name="android.permission.INTERNET"> en sus archivos de manifiesto. Para adquirir 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 sus widgets de la pantalla principal se puedan cambiar de tamaño, ya sea de forma horizontal, 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 se pueda cambiar el tamaño de cualquier widget de la pantalla principal definiendo un atributo resizeMode en los metadatos AppWidgetProviderInfo del widget. Los valores del atributo resizeMode incluyen "horizontal", "vertical" y "none". Para declarar que un widget puede cambiar de tamaño de forma 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 de 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 el ViewPropertyAnimator es sencillo. Para animar las propiedades de un View, llama a animate() para construir un objeto ViewPropertyAnimator para ese View. Usa los métodos en ViewPropertyAnimator para especificar qué propiedad animar y cómo hacerlo. Por ejemplo, para que el View se atenúe hasta volverse transparente, llama a alpha(0);. El objeto ViewPropertyAnimator controla los detalles de la configuración de la clase Animator subyacente y la inicia para, luego, renderizar la animación.

  • Color de fondo de la animación
    • Los nuevos métodos getBackgroundColor() y setBackgroundColor(int) te permiten obtener o establecer el color de fondo detrás de las animaciones, solo para las animaciones de ventanas. Actualmente, el fondo debe ser negro, con cualquier nivel alfa deseado.
  • Obteniendo la fracción animada de ViewAnimator
    • Un nuevo método getAnimatedFraction() te permite obtener la fracción de animación actual, es decir, la fracción transcurrida o interpolada que se usó en la actualización de fotogramas más reciente, 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 que la View se renderice en ella de inmediato. Por ejemplo, una aplicación podría usar este método para renderizar un objeto View en su capa antes de iniciar una animación. Si la vista es compleja, renderizarla en la capa antes de iniciar la animación evitará que se omitan fotogramas.
  • Distancia de la cámara
    • Las aplicaciones pueden usar un método nuevo, setCameraDistance(float), para establecer la distancia de la cámara a una vista. Esto brinda a las aplicaciones un mejor control sobre las transformaciones en 3D de la vista, como las rotaciones.
  • Obtén una vista de calendario desde un DatePicker
  • Cómo obtener devoluciones de llamada cuando se desconectan las vistas
  • Se agregó un objeto de escucha de rutas de navegación de fragmentos y una nueva firma onInflate()
  • Mostrar el resultado de la búsqueda en una pestaña nueva
  • Cursor de texto de elemento de diseño
    • Ahora puedes especificar un elemento de diseño para usarlo como cursor de texto con el nuevo atributo de recurso textCursorDrawable.
  • Cómo configurar el 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 admitir 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 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 algunos parámetros de configuración (como RGB_565), se ignora esta llamada, ya que no admite valores alfa por píxel. Esto se usa como sugerencia de dibujo, ya que, en algunos casos, un mapa de bits que se sabe que es opaco puede tomar un caso de dibujo más rápido que uno que puede tener valores alfa por píxel no opacos.
    • getByteCount() obtiene el tamaño de un mapa de bits en bytes.
    • getGenerationId() permite que una aplicación descubra 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 la dimensión, la configuración o los datos de píxeles.
  • Configura 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. Debido a que usa más energía, las aplicaciones deben adquirir el Wi-Fi de alto rendimiento cuando se necesita una conexión activa de larga duración.

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

  • Más estadísticas de tráfico
    • Las aplicaciones ahora 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 de 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 de SIP
    • Ahora, las aplicaciones pueden obtener y establecer el nombre de usuario de autenticación de SIP para un perfil con los nuevos métodos getAuthUserName() y setAuthUserName().

Administrador de descargas

  • Control de las descargas completadas
    • Ahora, las aplicaciones pueden iniciar descargas que notifican a los usuarios solo cuando se completan. 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 nuevo método, addCompletedDownload(), permite que una aplicación agregue un archivo a la base de datos de descargas, de modo que la aplicación de Descargas pueda administrarlo.
  • Mostrar descargas ordenadas por tamaño

Framework de IME

  • Obtén la clave de valor adicional de un método de entrada

Medios

  • Nuevos formatos de transmisión de audio
    • El framework de contenido multimedia agrega compatibilidad integrada con contenido AAC ADTS sin procesar para mejorar la transmisión de audio, así como compatibilidad con audio FLAC para contenido de audio comprimido de la más alta calidad (sin pérdidas). Consulta el documento Formatos de contenido multimedia 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 en estado detenido y proporciona un medio para controlar su inicio desde procesos en segundo plano y otras aplicaciones.

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

La plataforma define dos marcas de intents nuevas que permiten que un remitente especifique si se debe permitir que el intent active componentes en una aplicación detenida.

Cuando no se define ninguna de estas marcas o ambas en un intent, el comportamiento predeterminado es incluir filtros de aplicaciones detenidas en la lista de destinos potenciales.

Ten en cuenta que el sistema agrega FLAG_EXCLUDE_STOPPED_PACKAGES a todos los intents de transmisión. Esto evita que las transmisiones de los servicios en segundo plano inicien de forma involuntaria o innecesaria componentes de aplicaciones detenidas. Un servicio o una aplicación 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 las aplicaciones detenidas.

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

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

La plataforma agrega una notificación mejorada del primer inicio y las actualizaciones de la aplicación a través de dos nuevas acciones de intents:

  • 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ó y que se instaló una versión nueva sobre una existente. Este mensaje solo se envía a la aplicación que se reemplazó. No contiene datos adicionales. Para recibirlo, declara un filtro de intents para esta acción. Puedes usar el intent para activar el código que ayuda a que tu 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 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 que se dedica a calcular o descargar datos de la red, a la vez que se mantiene un espacio en memoria razonable para los datos almacenados en caché.LruCache es una caché que contiene referencias sólidas a una cantidad limitada de valores. Cada vez que se accede a un valor, este se mueve al principio de una cola. Cuando se agrega un valor a una caché completa, se expulsa el valor que se encuentra al final de esa cola y puede ser apto para la recolección de elementos no utilizados.
  • Descriptor de archivo como int

WebKit

  • Cookies de esquema de archivo
    • 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 archivo antes de construir una instancia de WebView o CookieManager. En una instancia de CookieManager, puedes llamar a allowFileSchemeCookies() para verificar si las cookies de esquema de archivo están habilitadas.
  • 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 alojada que se procesó una solicitud de acceso automático para el usuario.
  • Clases e interfaces quitadas
    • Se quitaron varias clases e interfaces de la API pública, después de que se encontraran en estado de baja. Consulta el Informe de diferencias de la API 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 se acelera por hardware siempre que sea posible.
  • Compatibilidad de capas con elementos de posición fija para 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, sobre 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 <uses-feature>. Para obtener más información sobre cómo declarar funciones en un manifiesto de la aplicación, consulta Filtros de Google Play.

Informe de diferencias de la API

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 la API.

Nivel de API

La plataforma de 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 el sistema antes de instalarla.

Para usar las APIs que se introdujeron en Android 3.1 en tu aplicación, debes 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?