API de Android 3.1

Nivel de API: 12

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

Para los desarrolladores, la plataforma Android 3.1 está disponible como componente descargable para el SDK de Android. La plataforma descargable incluye una biblioteca de Android y una imagen del sistema, así como un conjunto de máscaras de emulador y 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 los 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 y potentes APIs para integrar periféricos conectados con aplicaciones que se ejecuten en la plataforma. Las APIs se basan en una pila y servicios USB (bus universal en serie) que están integrados en la plataforma, lo que incluye compatibilidad con interacciones de host y dispositivo USB. Con las APIs, los desarrolladores pueden crear aplicaciones que puedan descubrir, comunicarse 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, que se basan en si el dispositivo con Android actúa como host o el hardware externo. actúa como host:

  • Un dispositivo USB es una pieza de hardware conectado que depende del Dispositivo con Android que se usará 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 cable USB. controlador de host, suministra energía y está diseñado para comunicarse con a través de USB, una variedad de periféricos pueden conectarse como accesorios, desde controladores robóticos hasta equipos musicales, bicicletas estáticas, y más.

Para ambos tipos (dispositivos 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. El la clase central es UsbManager, que proporciona métodos auxiliares para identificarse y comunicarse dispositivos y accesorios USB. Las aplicaciones pueden adquirir una instancia de UsbManager y, luego, consulta la lista de archivos adjuntos dispositivos o accesorios y, luego, comunicarte con ellos o administrarlos. UsbManager también declara las acciones de intent que el del sistema, para anunciar cuando hay un dispositivo o accesorio USB conectado o independiente.

Entre otras clases, se incluyen las siguientes:

  • UsbDevice, una clase que representa hardware conectado como un dispositivo USB (con el dispositivo con Android que actúa como host).
  • UsbAccessory, que representa el hardware externo conectado como host USB (con el dispositivo con Android que actúa como USB) dispositivo).
  • UsbInterface y UsbEndpoint, que proporcionan acceso a USB estándar interfaces y extremos de un dispositivo.
  • UsbDeviceConnection y UsbRequest, para enviar y recibir datos y mensajes de control a 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.

Ten en cuenta que, aunque la pila USB está integrada en la plataforma, la compatibilidad real para los modos de host USB y de accesorio abierto en dispositivos específicos está determinado por a sus fabricantes. En particular, el modo de host depende de los puertos el hardware del control de acceso en el dispositivo con Android.

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

  • Si la aplicación solo debería ser visible para dispositivos compatibles con USB modo de host (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 compatibles con USB accesorios (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úan con accesorios USB, consulta la documentación para desarrolladores.

Para ver ejemplos de aplicaciones que usan la API del host USB, consulta Prueba ADB y Misiles Selector

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 para recibir notificaciones cuando los dispositivos se conectan y quitan, administrar archivos y almacenamiento en esos dispositivos, y transferir archivos y metadatos a y de ellas. La API de MTP implementa el subconjunto de PTP (protocolo de transferencia de imágenes). de la especificación de MTP (protocolo de transferencia multimedia).

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

  • El MtpDevice encapsula un dispositivo MTP que es que está conectada a través del bus host USB. Una aplicación puede crear una instancia de un objeto de este tipo y luego usa 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. Algunos de los métodos incluyen los siguientes:
    • getObjectHandles() muestra una lista de controladores para todos los objetos del dispositivo que coincidan con un formato y elemento superior especificados. Para obtener información sobre un objeto, una aplicación puede pasar un identificador a getObjectInfo().
    • importFile() permite que una aplicación copie los datos de un objeto a un archivo en un entorno externo y almacenamiento de los datos. Esta llamada puede bloquearse durante un período arbitrario según la el tamaño de los datos y la velocidad de los dispositivos, por lo que se debe hacer conversación.
    • open() permite que una aplicación abra un dispositivo MTP/PTP conectado.
    • Devoluciones por getThumbnail() la miniatura del objeto como un array de bytes.
  • MtpStorageInfo conserva información sobre un almacenamiento en un dispositivo MTP, que corresponde al conjunto de datos StorageInfo descrito en 5.2.2 de la especificación de MTP. Los métodos de la clase permiten que una aplicación obtener 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 conserva la información sobre un dispositivo MTP. correspondiente al conjunto de datos DeviceInfo descrito en la sección 5.1.1 de la MTP especificación. Los métodos de la clase permiten que las aplicaciones obtengan la información de un dispositivo fabricante, modelo, número de serie y versión.
  • 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 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 el archivo MTP. los códigos de formato, el tipo de asociación y el estado de protección.

Compatibilidad con nuevos dispositivos de entrada y eventos de movimiento

Android 3.1 amplía 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 usando mouse, bolas de seguimiento, joysticks, mandos para videojuegos 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 nuevas de eventos de movimiento:

  • ACTION_SCROLL, que describe la ubicación del puntero en la que se produjo un movimiento de desplazamiento no táctil, como el de la rueda del mouse. En MotionEvent, el valor de los ejes AXIS_HSCROLL y AXIS_VSCROLL especifica el desplazamiento relativo. movimiento.
  • ACTION_HOVER_MOVE, informa el valor actual del mouse cuando no se presiona ningún botón, así como cualquier puntos desde el último evento de HOVER_MOVE. Coloca el cursor sobre Intro y Salir aún no se admiten las notificaciones.

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

Para describir eventos de movimiento de estas nuevas fuentes, así como de 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. Nuevos códigos de eje para joysticks y los 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 la cantidad de objetos códigos de eje que se usan cuando el framework no sabe cómo asignar una en un eje determinado. Ciertos dispositivos pueden usar los códigos de eje genéricos para pasar códigos datos de movimiento a las aplicaciones. Para obtener una lista completa de los ejes y sus interpretaciones, 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 llamados 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 el de muestra 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 múltiples fuentes. Cuando un dispositivo proporciona múltiples fuentes, se activa más de una. puedes proporcionar datos de eje usando el mismo eje. Por ejemplo, si llega un evento táctil de la fuente táctil usa el eje X para los datos de posición de la pantalla, mientras que un joystick que provenga de la fuente del joystick usará el eje X para la posición de la barra en su lugar. Por este motivo, es importante que las aplicaciones interpreten los ejes de salida según la fuente de donde se originan. Cuando se manipula un movimiento las aplicaciones deben usar métodos en InputDevice para determinar los ejes compatibles con 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 un determinado fuente del dispositivo. En ambos casos, la información de rango para ejes devuelta en el objeto InputDevice.MotionRange especifica la fuente del para cada valor de eje.

Por último, como los eventos de movimiento de los joysticks, los gamepads, los ratones 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 los View a través de una llamada a onGenericMotionEvent(), en lugar de a onTouchEvent().

La plataforma envía eventos genéricos de movimiento de manera diferente, según el la clase de origen del evento. SOURCE_CLASS_POINTER eventos ve a View debajo del puntero, de manera similar a como sucede los eventos funcionan. Todos los demás se dirigen al elemento View enfocado 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 actividad o diálogo implementando onGenericMotionEvent() allí.

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

API de RTP

Android 3.1 expone una API a su protocolo de transporte en tiempo real (RTP) integrado. que las aplicaciones pueden usar para administrar datos interactivos o según demanda transmisión. En particular, las apps que brindan VoIP, presionar para hablar, conferencias y la transmisión de audio pueden usar la API para iniciar sesiones y transmitir o recibir flujos de datos en cualquier red disponible.

La API de RTP está disponible en el paquete android.net.rtp. Clases incluyen:

  • RtpStream, la clase base de transmisiones que envían y recibir paquetes de red con cargas útiles de medios 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 que combina 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 videoconferencias y usos similares, una aplicación crea una instancia dos clases como extremos de la transmisión:

El uso más simple implica un único 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. Para ello, deben declarar <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 cambien de tamaño horizontal o verticalmente, o en ambos ejes. Los usuarios deben mantener presionado un widget para mostrar los controladores de cambio de tamaño y, luego, arrastrar los controladores de forma horizontal y/o vertical 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 El atributo resizeMode en los metadatos AppWidgetProviderInfo del widget. Valores para el El atributo resizeMode incluye “horizontal”, “vertical” y “ninguno”. 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 de Widgets de apps.

Framework de animación

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

      Usar ViewPropertyAnimator es sencillo. Para animar propiedades de un View, llama a animate() para construir un objeto ViewPropertyAnimator para ese View. Usa el en ViewPropertyAnimator para especificar a qué propiedad y cómo hacerlo. Por ejemplo, para atenuar el View a transparente, haz lo siguiente: llama a alpha(0);. El objeto ViewPropertyAnimator se encarga de los detalles de configuración de la clase Animator subyacente, iniciarla y, luego, renderizar la clase animación.

  • Color de fondo de la animación
    • Nuevo getBackgroundColor() y Los métodos setBackgroundColor(int) permiten obtienes o estableces el color de fondo detrás de las animaciones para las animaciones de ventanas solamente. Actualmente, el fondo debe ser negro, con cualquier nivel alfa deseado.
  • Obteniendo fracción animada de ViewAnimator
    • Un nuevo método getAnimatedFraction() te permite obtener la fracción de animación actual (la fracción transcurrido/interpolada usada en la actualización de fotogramas más reciente) de un ValueAnimator.

Framework de IU

  • Representación forzada de una capa
    • Un nuevo método buildLayer() permite que una aplicación forzar la creación de una capa de un elemento View y la renderización de la vista en ella de inmediato. Por ejemplo, una aplicación podría usar este método para renderizar una vista en su rugosidad 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 nuevo método setCameraDistance(float) para configurar la distancia cámara a un objeto View. Esto les brinda a las aplicaciones un control mejorado sobre las transformaciones 3D de la vista, como rotaciones.
  • Cómo obtener una vista de calendario desde un selector de fecha
  • Obtención de devoluciones de llamada cuando se desconectan las vistas
  • Objeto de escucha de ruta de navegación de fragmentos, nueva firma de 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 un en una pestaña nueva del navegador, en lugar de en una existente.
  • Cursor de texto de elementos de diseño
    • Ahora puedes especificar un elemento de diseño para usar como cursor de texto con el nuevo el atributo de recurso textCursorDrawable.
  • Configuración del elemento secundario mostrado en vistas remotas
  • Teclas genéricas para controles de juegos y otros dispositivos de entrada
    • KeyEvent agrega una variedad de códigos de teclas genéricos para adaptarse a los botones del mando de juegos. La clase también agrega isGamepadButton(int) y varias más de ayuda para trabajar con códigos de teclas.

Gráficos

  • Ayudas para administrar mapas de bits
    • setHasAlpha(boolean) permite que una app indique lo siguiente: se sabe que todos los píxeles de un mapa de bits son opacos (falso) o que algunos de los los píxeles pueden contener valores alfa no opacos (verdadero). Ten en cuenta que, para algunos parámetros de configuración (como como RGB_565), esta llamada se ignora, ya que no es compatible con alfa por píxel. de salida. Esto se indica como una sugerencia de dibujo, ya que, en algunos casos, un mapa de bits que se sabe que es opaco puede tener 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 encuentre si un mapa de bits se modificó, 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 la dimensión, la configuración o los datos de píxeles.
  • Cómo configurar la rotación y la ubicación de la cámara
    • Camera agrega dos métodos nuevos, rotate() y setLocation(), para el control de la la ubicación de la cámara para las transformaciones en 3D.

Red

  • Bloqueo de Wi-Fi de alto rendimiento
    • Una nueva cerradura Wi-Fi de alto rendimiento permite que las aplicaciones mantengan conexiones Wi-Fi de alto rendimiento, incluso con la pantalla apagada. Las aplicaciones que transmiten música, video o voz durante largos períodos pueden adquirir la bloqueo de Wi-Fi de alto rendimiento para garantizar el rendimiento de la transmisión, incluso cuando la pantalla está desactivada. Debido a que usa más energía, las aplicaciones deben adquirir de alto rendimiento cuando se necesita una conexión Wi-Fi activa conexión.

      Para crear un bloqueo de alto rendimiento, pasa WIFI_MODE_FULL_HIGH_PERF como el modo bloqueado en un 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 el para obtener estadísticas de UDP, recuento de paquetes, bytes de carga útil de transmisión/recepción de TCP y para un UID determinado.
  • Nombre de usuario de autenticación SIP
    • Las aplicaciones ahora pueden obtener y configurar el nombre de usuario de autenticación SIP para un perfil mediante los nuevos métodos getAuthUserName() y setAuthUserName().

Administrador de descargas

  • Manejo de las descargas completadas
    • Ahora las aplicaciones pueden iniciar descargas que notifican a los usuarios solo en del proyecto. Para iniciar este tipo de descarga, las aplicaciones pasan VISIBILITY_VISIBLE_NOTIFY_ONLY_COMPLETION en el método setNotificationVisibility() de el objeto Request.
    • Un nuevo método, addCompletedDownload(), permite que una aplicación agregue un archivo al de descargas de la base de datos, de modo que pueda ser administrada por la aplicación de Descargas.
  • Cómo 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 AAC ADTS 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 contenido multimedia compatibles para obtener más información.

Controles de inicio en los dispositivos detenidos aplicaciones

A partir de Android 3.1, el administrador de paquetes del sistema realiza un seguimiento de que están en estado detenido y proporcionan una forma de controlar su lanzamiento a partir de procesos en segundo plano y otras aplicaciones.

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

La plataforma define dos nuevas marcas de intent que permiten que un remitente especifique si se le debe permitir al intent activar componentes en objetos y mantener la integridad de su aplicación.

Cuando ninguna de estas marcas (o ambas) se define en un intent, el valor 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 todas las transmisiones intents. Lo hace para evitar que las emisiones de los servicios en segundo plano iniciar, de forma involuntaria o innecesaria, componentes de aplicaciones detenidas Un servicio o una aplicación en segundo plano puede anular este comportamiento agregando Marca FLAG_INCLUDE_STOPPED_PACKAGES para transmitir que deben poder activar aplicaciones detenidas.

Las aplicaciones se encuentran en un 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 de la aplicación y las actualizaciones a través de dos nuevas acciones de intent:

  • ACTION_PACKAGE_FIRST_LAUNCH: Se envió a el 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 versión existente. Esto solo se envía a la aplicación que se reemplazó. Integra no contiene ningún dato adicional. 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 esta se actualizó mientras estaba en estado iniciado (no detenido).

Utilidades principales

  • Caché de LRU
    • Una nueva clase LruCache permite que tus aplicaciones se beneficien de un almacenamiento en caché eficiente. Las aplicaciones pueden usar la clase para reducir el tiempo dedicado calcular o descargar datos de la red, mientras se mantiene un espacio en memoria para los datos almacenados en caché.LruCache es una caché que contiene referencias fuertes a un número limitado de valores. Cada vez que se agrega un valor si accedes, se mueve al encabezado de una cola. Cuando se agrega un valor a una al final, se expulsa y puede ser apto para la recolección de elementos no utilizados.
  • Descriptor de archivos como int

WebKit

  • Cookies de esquema de archivos
    • CookieManager ahora admite cookies que usan el esquema de URI file:. Puedes usar setAcceptFileSchemeCookies() para lo siguiente: habilitar/inhabilitar la compatibilidad con cookies de esquema de archivos antes de construir una instancia de WebView o CookieManager. En una instancia CookieManager, puedes verificar si las cookies de esquema de archivos se habilita llamando a allowFileSchemeCookies().
  • Notificación de solicitud de acceso
    • Para admitir las funciones de inicio de sesión automático del navegador presentadas en Android 3.0, la interfaz nuevo método onReceivedLoginRequest() notifica al host aplicación de que se procesó una solicitud de acceso automático para el usuario.
  • Clases e interfaces que se quitaron
    • Varias clases e interfaces se quitaron de la API pública, después que antes estaban en estado obsoleto. Consulta la página Informe de diferencias para obtener más información.

Navegador

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

  • Compatibilidad con la reproducción intercalada de videos incorporados en HTML5 <video>. La reproducción se acelera con hardware siempre que sea posible.
  • Compatibilidad con capas para elementos de posición fija para todos los sitios (dispositivos móviles y una computadora 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 Juego de los requisitos de la aplicación para las nuevas capacidades de hardware compatibles en esta versión de la plataforma. Los desarrolladores declaran estas y otras funciones constantes en los elementos del manifiesto <uses-feature>.

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

Informe de diferencias de las APIs

Puedes obtener una vista detallada de todos los cambios de la API en Android 3.1 (API Nivel 12), consulta la sección Informe de diferencias.

Nivel de API

La plataforma Android 3.1 ofrece una versión actualizada de la API del framework. La API de Android 3.1 se le asigna un identificador de número entero, 12: Es decir, almacenados en el sistema. Este identificador, llamado “nivel de API”, permite que la para determinar de forma correcta si una aplicación es compatible con en el sistema antes de instalar la aplicación.

Para usar en tu aplicación las APIs que se introdujeron en Android 3.1, debes compilar la aplicación en la biblioteca de Android que se proporciona en la plataforma del SDK de Android 3.1. Según tus necesidades, podría también debes agregar un android:minSdkVersion="12" al elemento <uses-sdk> en la carpeta de la aplicación .

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