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
yUsbEndpoint
, que proporcionan acceso a extremos y interfaces USB estándar para un dispositivo.UsbDeviceConnection
yUsbRequest
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 agetObjectInfo()
.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 ejesAXIS_HSCROLL
yAXIS_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 eventoHOVER_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:
SOURCE_CLASS_JOYSTICK
: El dispositivo de origen tiene ejes de joystick.SOURCE_CLASS_BUTTON
: El dispositivo de origen tiene botones o teclas.SOURCE_GAMEPAD
: El dispositivo de origen tiene botones de control de juegos, comoKEYCODE_BUTTON_A
oKEYCODE_BUTTON_B
. ImplicaSOURCE_CLASS_BUTTON
SOURCE_JOYSTICK
: El dispositivo de origen tiene ejes de joystick. implica SOURCE_CLASS_JOYSTICK.
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 deRtpStream
que lleva cargas útiles de audio a través de RTPAudioGroup
, un concentrador de audio local para administrar y combinar la bocina del dispositivo, el micrófono yAudioStream
.AudioCodec
, que contiene una colección de códecs que defines para unAudioStream
.
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 unAudioCodec
configurado.AudioGroup
representa el extremo local de uno o más objetosAudioStream
. ElAudioGroup
mezcla todas lasAudioStream
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 objetosView
. La clase automatiza y optimiza la animación de las propiedades y facilita la administración de varias animaciones simultáneas en un objetoView
.El uso de
ViewPropertyAnimator
es sencillo. Para animar propiedades para unView
, llama aanimate()
para construir un objetoViewPropertyAnimator
para esaView
. Usa los métodos deViewPropertyAnimator
para especificar qué propiedad animar y cómo hacerlo. Por ejemplo, para atenuarView
a transparente, llama aalpha(0);
. El objetoViewPropertyAnimator
controla los detalles de configuración de la claseAnimator
subyacente, su inicio y, luego, la renderización de la animación.
- Una nueva clase
- Color de fondo de la animación
- Los nuevos métodos
getBackgroundColor()
ysetBackgroundColor(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.
- Los nuevos métodos
- 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 unValueAnimator
.
- Un nuevo método
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.
- Un nuevo método
- 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.
- Las aplicaciones pueden usar un nuevo método
- Obtén una vista de calendario con un selector de fecha
- Un nuevo método
getCalendarView()
te permite obtener unCalendarView
de una instancia deDatePicker
.
- Un nuevo método
- Obtén devoluciones de llamada cuando se desconectan las vistas
- Un
View.OnAttachStateChangeListener
nuevo te permite recibir devoluciones de llamada cuando se adjunta o se desconecta una vista de su ventana. UsaaddOnAttachStateChangeListener()
para agregar un objeto de escucha yaddOnAttachStateChangeListener()
si quieres quitarlo.
- Un
- Objeto de escucha de ruta de navegación de fragmentos, nueva firma onInflate()
- Un método nuevo,
setOnBreadCrumbClickListener()
, proporciona un hook para permitir que las aplicaciones intercepten clics de rutas de navegación de fragmentos y realicen cualquier acción necesaria antes de dirigirse a la entrada de la pila de actividades o al fragmento en el que se hizo clic. - En la clase
Fragment
,onInflate(attrs, savedInstanceState)
dejó de estar disponible. En su lugar, usaonInflate(activity, attrs, savedInstanceState)
.
- Un método nuevo,
- Mostrar el resultado de la búsqueda en una pestaña nueva
- Una clave de datos
EXTRA_NEW_SEARCH
para intentsACTION_WEB_SEARCH
te permite abrir una búsqueda en una pestaña del navegador nueva, en lugar de en una existente.
- Una clave de datos
- 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
.
- Ahora puedes especificar un elemento de diseño para usar como cursor de texto usando el nuevo atributo de recurso
- Configuración del elemento secundario que se muestra en las vistas remotas
- Un nuevo método de conveniencia,
setDisplayedChild(viewId, childIndex)
, está disponible en las subclasesRemoteViews
para permitirte configurar el elemento secundario que se muestra en las subclasesViewAnimator
yAdapterViewAnimator
, comoAdapterViewFlipper
,StackView
,ViewFlipper
yViewSwitcher
.
- Un nuevo método de conveniencia,
- 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 agregaisGamepadButton(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
Camera
agrega dos métodos nuevos,rotate()
ysetLocation()
, para controlar la ubicación de la cámara en transformaciones 3D.
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 acreateWifiLock()
.
- 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.
- 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.
- Las aplicaciones ahora pueden acceder a las estadísticas sobre más tipos de uso de red con métodos nuevos en
- 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()
ysetAuthUserName()
.
- Las aplicaciones ahora pueden obtener y establecer el nombre de usuario de autenticación de SIP de un perfil mediante los nuevos métodos
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étodosetNotificationVisibility()
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.
- Las aplicaciones ahora pueden iniciar descargas que notifican a los usuarios solo cuando finalizan. Para iniciar este tipo de descarga, las aplicaciones pasan
- Mostrar las descargas ordenadas por tamaño
- Las aplicaciones pueden iniciar la aplicación de descargas en modo de orden por tamaño agregando el nuevo
INTENT_EXTRAS_SORT_BY_SIZE
adicional a un intentACTION_VIEW_DOWNLOADS
.
- Las aplicaciones pueden iniciar la aplicación de descargas en modo de orden por tamaño agregando el nuevo
Marco de IME
- Cómo obtener la clave de valor adicional de un método de entrada
InputMethodSubtype
agrega el métodocontainsExtraValueKey()
a fin de verificar si se almacena una string ExtraValue para el subtipo y el métodogetExtraValueOf()
para extraer un par clave-valor específico del mapa de hash ExtraValue.
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.
FLAG_INCLUDE_STOPPED_PACKAGES
: Incluye filtros de intents de aplicaciones detenidas en la lista de objetivos potenciales con los que se deben resolver.FLAG_EXCLUDE_STOPPED_PACKAGES
: Excluye los filtros de intents de las aplicaciones detenidas de la lista de objetivos potenciales.
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.
- Una nueva clase
- Descriptor de archivo como
int
- Ahora puedes obtener el descriptor de archivos nativo int para una
ParcelFileDescriptor
mediante cualquiera de los nuevos métodosgetFd()
odetachFd()
- Ahora puedes obtener el descriptor de archivos nativo int para una
WebKit
- Cookies de esquema de archivos
CookieManager
ahora admite cookies que usan el esquema de URIfile:
. Puedes usarsetAcceptFileSchemeCookies()
para habilitar o inhabilitar la compatibilidad con las cookies de esquema de archivos antes de construir una instancia deWebView
oCookieManager
. En una instancia deCookieManager
, puedes verificar si las cookies de esquema de archivos están habilitadas llamando aallowFileSchemeCookies()
.
- 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.
- Para admitir las funciones de acceso automático del navegador que se introdujeron en Android 3.0, el nuevo método
- 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>
.
android.hardware.usb.accessory
: La aplicación usa la API de USB para comunicarse con dispositivos de hardware externos conectados a través de USB y funcionar como hosts.android.hardware.usb.host
: La aplicación usa la API de USB para comunicarse con dispositivos de hardware externos conectados a través de USB y funcionar como dispositivos.
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?