API de Android 2.3

Nivel de API: 9

Para los desarrolladores, la plataforma de Android 2.3 (GINGERBREAD) 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 2.3, 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 en la versión 2.3, como las nuevas funciones y los cambios en la API de framework desde la versión anterior.

VoIP basado en SIP

La plataforma ahora incluye una pila de protocolo SIP y una API de framework que permite a los desarrolladores crear aplicaciones de telefonía por Internet. Con la API, las aplicaciones pueden ofrecer funciones de llamadas de voz sin tener que administrar sesiones, comunicación a nivel de transporte ni audio; estas se manejan con transparencia mediante la API y los servicios de SIP de la plataforma.

La API de SIP está disponible en el paquete android.net.sip. La clase clave es SipManager, que las aplicaciones usan para configurar y administrar perfiles SIP y, luego, iniciar llamadas de audio y recibirlas. Una vez que se establece una llamada de audio, las aplicaciones pueden silenciar llamadas, activar el modo de bocina, enviar tonos de DTMF y mucho más. Las aplicaciones también pueden usar SipManager para crear conexiones SIP genéricas.

La pila SIP subyacente y los servicios de la plataforma están disponibles en dispositivos a discreción del fabricante y el operador asociado. Por este motivo, las aplicaciones deben usar el método isApiSupported() para comprobar si la compatibilidad con SIP está disponible antes de exponer la funcionalidad de llamada a los usuarios.

Para usar la API de SIP, las aplicaciones deben solicitar permiso al usuario declarando <uses-permission android:name="android.permission.INTERNET"> y <uses-permission android:name="android.permission.USE_SIP"> en sus archivos de manifiesto.

Además, los desarrolladores pueden solicitar filtros en Google Play para que sus aplicaciones no sean detectables para los usuarios cuyos dispositivos no incluyan la pila y los servicios de SIP de la plataforma. Para solicitar el filtrado, agrega <uses-feature android:name="android.software.sip" android:required="true"> y <uses-feature android:name="android.software.sip.voip"> al manifiesto de la aplicación.

Para obtener más información, lee la guía para desarrolladores de SIP.

Comunicación de campo cercano (NFC)

Android 2.3 incluye una pila NFC y una API de framework que permiten a los desarrolladores leer etiquetas NDEF que se descubren cuando un usuario toca un dispositivo compatible con NFC para etiquetar elementos incorporados en calcomanías, pósteres inteligentes e incluso otros dispositivos.

La plataforma proporciona los servicios subyacentes de NFC que funcionan con el hardware del dispositivo para descubrir etiquetas cuando están dentro del alcance. Cuando descubre una etiqueta, la plataforma notifica a las aplicaciones mediante la transmisión de un intent y agrega los mensajes NDEF de la etiqueta al intent como extras. Las aplicaciones pueden crear filtros de intents para reconocer y controlar las etiquetas y los mensajes orientados. Por ejemplo, después de recibir una etiqueta del intent, las aplicaciones extraen los mensajes NDEF, los almacenan, alertan al usuario o los manejan de otras maneras.

La API de NFC está disponible en el paquete android.nfc. Las clases clave son:

  • NfcAdapter, que representa el hardware NFC en el dispositivo.
  • NdefMessage, que representa un mensaje de datos NDEF, el formato estándar en el que los "registros" que transportan datos se transmiten entre dispositivos y etiquetas. Las aplicaciones pueden recibir estos mensajes de intents ACTION_TAG_DISCOVERED.
  • NdefRecord, entregado en un NdefMessage, que describe el tipo de datos que se comparten y lleva los datos en sí.

La comunicación NFC se basa en la tecnología inalámbrica del hardware del dispositivo, por lo que sus fabricantes determinan la compatibilidad de las funciones NFC de la plataforma en dispositivos específicos. Para determinar la compatibilidad con NFC en el dispositivo actual, las aplicaciones pueden llamar a isEnabled() para consultar el NfcAdapter. Sin embargo, la API de NFC siempre está presente, independientemente de la compatibilidad de hardware subyacente.

Para usar la API de NFC, las aplicaciones deben solicitar permiso al usuario declarando <uses-permission android:name="android.permission.NFC"> en sus archivos de manifiesto.

Además, los desarrolladores pueden solicitar filtros en Google Play para que sus aplicaciones no sean detectables para los usuarios cuyos dispositivos no sean compatibles con NFC. Para solicitar el filtrado, agrega <uses-feature android:name="android.hardware.nfc" android:required="true"> al manifiesto de la aplicación.

Para ver una aplicación de ejemplo que usa la API de NFC, consulta NFCDemo.

Giroscopio y otros sensores

Android 2.3 agrega compatibilidad con plataformas y API para varios tipos de lectura de sensores nuevos: giroscopio, vector de rotación, aceleración lineal, gravedad y barómetro. Los desarrolladores pueden usar las nuevas lecturas del sensor para crear aplicaciones que respondan de manera rápida y fluida a cambios precisos en la posición y el movimiento del dispositivo. La API de Sensor informa los cambios del giroscopio y otros cambios del sensor a las aplicaciones interesadas, ya sea que se ejecuten en el framework de la aplicación o en código nativo.

Ten en cuenta que el conjunto específico de sensores de hardware disponibles en un dispositivo determinado varía a discreción del fabricante.

Los desarrolladores pueden solicitar filtros en Google Play para que sus aplicaciones no sean detectables para los usuarios cuyos dispositivos no ofrezcan un sensor de giroscopio. Para ello, agrega <uses-feature android:name="android.hardware.sensor.gyroscope" android:required="true"> al manifiesto de la aplicación.

Para obtener detalles de la API, consulta Sensor.

Compatibilidad con varias cámaras

Ahora las aplicaciones pueden usar cualquier cámara disponible en un dispositivo para captura de fotos o video. Camera permite que las aplicaciones consulten la cantidad de cámaras disponibles y las características únicas de cada una.

  • La nueva clase Camera.CameraInfo almacena las características de posición de una cámara (orientación, orientación frontal o posterior).
  • Los nuevos métodos getNumberOfCameras() y getCameraInfo() en la clase Camera permiten que las aplicaciones consulten las cámaras disponibles y abran la cámara que necesitan.
  • El nuevo método get() permite que las aplicaciones recuperen un CamcorderProfile para una cámara específica.
  • El nuevo getJpegEncodingQualityParameter() permite que las aplicaciones obtengan el nivel de calidad de captura de imagen estática para una cámara específica.

Si deseas ver el código de muestra para acceder a una cámara frontal, consulta CameraPreview.java en la aplicación de ejemplo ApiDemos.

La API de Camera también agrega lo siguiente:

Efectos de audio mezclables

El framework multimedia de la plataforma agrega compatibilidad con nuevos efectos de audio globales o por pista, como potenciación de bajos, virtualización de auriculares, ecualización y reverberación.

Para ver el código de muestra para los efectos de audio, consulta AudioFxDemo.java en la aplicación de ejemplo ApiDemos.

El framework de medios también agrega lo siguiente:

  • Nueva compatibilidad con la etiqueta de altitud en los metadatos EXIF para archivos JPEG Se agregó el nuevo método getAltitude() para recuperar el valor de la etiqueta de altitud EXIF.
  • El nuevo método setOrientationHint() permite que una aplicación le indique a MediaRecorder la orientación durante la captura de video.

Administrador de descargas

La plataforma incluye un nuevo servicio del sistema DownloadManager que controla descargas HTTP de larga duración. Las aplicaciones pueden solicitar que se descargue un URI en un archivo de destino específico. DownloadManager realizará la descarga en segundo plano, se encargará de las interacciones HTTP y volverá a intentar las descargas después de fallas o durante cambios de conectividad y reinicios del sistema.

  • Para obtener una instancia de la clase DownloadManager, las aplicaciones pueden llamar a getSystemService(String) y pasar DOWNLOAD_SERVICE. Las aplicaciones que solicitan descargas a través de esta API deben registrar un receptor de emisión para ACTION_NOTIFICATION_CLICKED, a fin de controlar de forma adecuada cuando el usuario hace clic en una descarga en ejecución en una notificación o desde la IU de descargas.
  • La clase DownloadManager.Request permite que una aplicación proporcione toda la información necesaria para solicitar una descarga nueva, como el URI de la solicitud y el destino de la descarga. Un URI de solicitud es el único parámetro obligatorio. Ten en cuenta que el destino de descarga predeterminado es un volumen compartido en el que el sistema puede borrar el archivo si necesita reclamar espacio para usarlo. Para el almacenamiento continuo de una descarga, especifica un destino de descarga en el almacenamiento externo (consulta setDestinationUri(Uri)).
  • La clase DownloadManager.Query proporciona métodos que permiten que una aplicación consulte y filtre las descargas activas.

Modo estricto

Para ayudar a los desarrolladores a supervisar y mejorar el rendimiento de sus aplicaciones, la plataforma ofrece una nueva instalación del sistema llamada StrictMode. Cuando se implementa en una aplicación, StrictMode detecta y notifica al desarrollador sobre una actividad accidental en el disco o en la red que podría degradar el rendimiento de la aplicación, como la actividad que tiene lugar en el subproceso principal de la aplicación (cuando se reciben operaciones de la IU y también se realizan animaciones). Los desarrolladores pueden evaluar los problemas de uso del disco y la red que se plantean en StrictMode y corregirlos si es necesario, lo que mantiene la capacidad de respuesta del subproceso principal y evita que se muestren diálogos de ANR a los usuarios.

  • StrictMode es la clase principal y es el punto de integración principal con el sistema y la VM. Esta clase proporciona métodos convenientes para administrar las políticas de VM y subprocesos que se aplican a la instancia.
  • StrictMode.ThreadPolicy y StrictMode.VmPolicy contienen las políticas que defines y aplicas al subproceso y a las instancias de VM.

Si quieres obtener más información para usar StrictMode a fin de optimizar tu aplicación, consulta la documentación de la clase y el código de muestra en android.os.StrictMode.

Framework de IU

  • Compatibilidad con el sobredesplazamiento
    • Nueva compatibilidad con el sobredesplazamiento en Views y Widgets. En Views, las aplicaciones pueden habilitar o inhabilitar el sobredesplazamiento para una vista determinada, configurar el modo de sobredesplazamiento, controlar la distancia del sobredesplazamiento y controlar los resultados del sobredesplazamiento.
    • En los widgets, las aplicaciones pueden controlar las características de sobredesplazamiento, como la animación, el springback y la distancia de sobredesplazamiento. Para obtener más información, consulta android.view.View y android.widget.OverScroller.
    • ViewConfiguration también proporciona los métodos getScaledOverflingDistance() y getScaledOverscrollDistance().
    • Nuevos atributos overScrollMode, overScrollFooter y overScrollHeader para elementos <ListView> para controlar el comportamiento de sobredesplazamiento.
  • Compatibilidad con el filtrado táctil
    • Nueva compatibilidad con el filtrado táctil, que permite que una aplicación mejore la seguridad de los objetos View que proporcionan acceso a funciones sensibles. Por ejemplo, el filtrado táctil es adecuado para garantizar la seguridad de las acciones del usuario, como otorgar una solicitud de permiso, realizar una compra o hacer clic en un anuncio. Para obtener más información, consulta Cómo ver la documentación de la clase.
    • Nuevo atributo filterTouchesWhenObscured para elementos de vista, que declara si se deben filtrar los toques cuando otra ventana visible oculta la ventana de la vista. Cuando se establece en "true", la vista no recibirá toques cada vez que aparezca un aviso, un diálogo o alguna otra ventana sobre la ventana de la vista. Consulta Consulta la documentación sobre seguridad para obtener más detalles.

    Para ver el código de muestra para el filtrado táctil, consulta SecureView.java en la aplicación de ejemplo ApiDemos.

  • Se mejoró la administración de eventos.
    • Nueva clase base para eventos de entrada, InputEvent. Esta clase proporciona métodos que permiten a las aplicaciones determinar el significado del evento, por ejemplo, a través de una consulta del InputDevice desde el que se originó el evento. KeyEvent y MotionEvent son subclases de InputEvent.
    • Nueva clase base para dispositivos de entrada, InputDevice. La clase almacena información sobre las capacidades de un dispositivo de entrada en particular y proporciona métodos que permiten a las aplicaciones determinar cómo interpretar eventos de un dispositivo de entrada.
  • Eventos de movimiento mejorados
    • La API de MotionEvent se extiende para incluir información del "ID de puntero", lo que permite a las aplicaciones realizar un seguimiento de los dedos individuales a medida que se mueven hacia arriba y hacia abajo. Esta clase agrega una variedad de métodos que permiten que una aplicación funcione de manera eficiente con eventos de movimiento.
    • El sistema de entrada ahora tiene lógica para generar eventos de movimiento con la nueva información del ID de puntero, sintetizando identificadores a medida que los punteros nuevos estén inactivos. El sistema realiza un seguimiento de varios IDs de puntero por separado durante un evento de movimiento y garantiza la continuidad adecuada de los punteros mediante la evaluación de la distancia entre el último y el siguiente conjunto de punteros.
  • Controles de selección de texto
    • Un nuevo método setComposingRegion permite que una aplicación marque una región de texto como texto compuesto, lo que mantiene el estilo actual. Un método getSelectedText muestra el texto seleccionado en la aplicación. Los métodos están disponibles en BaseInputConnection, InputConnection y InputConnectionWrapper.
    • Nuevos atributos textSelectHandle, textSelectHandleLeft, textSelectHandleRight y textSelectHandleWindowStyle para <TextView>, que permiten hacer referencia a elementos de diseño que se usarán para mostrar anclajes de selección de texto y el estilo de la ventana contenedora
  • Controles de actividad
  • Estilos de íconos y texto de notificaciones

    • Pantallas extragrandes

    La plataforma ahora admite tamaños de pantalla extragrandes, como los que se pueden encontrar en las tablets. Los desarrolladores pueden indicar que sus aplicaciones están diseñadas para admitir tamaños de pantalla extragrandes agregando un elemento <supports screens ... android:xlargeScreens="true"> a sus archivos de manifiesto. Las aplicaciones pueden usar un nuevo calificador de recursos, xlarge, para etiquetar recursos específicos de pantallas extragrandes. Para obtener detalles sobre cómo admitir pantallas extragrandes y otros tamaños de pantalla, consulta Compatibilidad con varias pantallas.

    Gráficos

    Proveedores de contenido

    • Nueva clase de proveedor AlarmClock para establecer o controlar una alarma El proveedor contiene una acción de intent ACTION_SET_ALARM y servicios adicionales que se pueden usar para iniciar una actividad a fin de establecer una alarma nueva en una aplicación de alarma. Las aplicaciones que desean recibir el intent SET_ALARM deben crear una actividad que requiera el permiso SET_ALARM. Las aplicaciones que deseen crear una alarma nueva deben usar Context.startActivity() para que el usuario tenga la opción de elegir qué aplicación de alarma usar.
    • MediaStore admite una nueva acción de intent, PLAY_FROM_SEARCH, que permite que una aplicación busque contenido multimedia musical y reproduzca contenido automáticamente desde el resultado cuando sea posible. Por ejemplo, una aplicación podría activar este intent como resultado de un comando de reconocimiento de voz para escuchar música.
    • MediaStore también agrega una nueva marca MEDIA_IGNORE_FILENAME que le indica al escáner multimedia que ignore el contenido del directorio que lo contiene y sus subdirectorios. Los desarrolladores pueden usar esta opción para evitar que aparezcan gráficos en la galería y, asimismo, para evitar que los sonidos y la música de la aplicación aparezcan en la app de Music.
    • El proveedor de Settings agrega las nuevas acciones de Activity APPLICATION_DETAILS_SETTINGS y MANAGE_ALL_APPLICATIONS_SETTINGS, que permiten que una aplicación muestre la pantalla de detalles de una aplicación específica o la pantalla Administrar aplicaciones.
    • El proveedor ContactsContract agrega el tipo de datos ContactsContract.CommonDataKinds.SipAddress para almacenar la dirección SIP (telefonía por Internet) de un contacto.

    Ubicación

    • LocationManager ahora realiza un seguimiento de las solicitudes de aplicaciones que generan bloqueos de activación o de Wi-Fi de acuerdo con WorkSource, una clase administrada por el sistema que identifica la aplicación.

      LocationManager realiza un seguimiento de todos los clientes que solicitan actualizaciones periódicas y les informa a sus proveedores sobre ellas como un parámetro WorkSource cuando configuran sus tiempos de actualización mínimos. El proveedor de ubicación de red usa WorkSource para realizar un seguimiento de los bloqueos de Wi-Fi y de activación que inicia una aplicación, y lo agrega al uso de batería de la aplicación que se informa en Administrar aplicaciones.

    • LocationManager agrega varios métodos nuevos que permiten que una actividad se registre para recibir actualizaciones de ubicación periódicas o únicas en función de criterios específicos (consulta a continuación).
    • Una nueva clase Criteria permite que una aplicación especifique un conjunto de criterios para seleccionar un proveedor de ubicación. Por ejemplo, los proveedores se pueden ordenar de acuerdo con la precisión, el uso de energía, la capacidad de informar sobre la altitud, la velocidad, el rumbo y el costo monetario.

    Almacenamiento

    • En Android 2.3, se agrega un StorageManager nuevo que admite archivos OBB (Opaque Binary Blob). Si bien la compatibilidad de la plataforma con OBB está disponible en Android 2.3, las herramientas de desarrollo para crear y administrar archivos OBB no estarán disponibles hasta principios de 2011.
    • La plataforma Android 2.3 agrega compatibilidad oficial para dispositivos que no incluyen tarjetas SD (aunque proporciona una partición de tarjeta SD virtual cuando no hay una tarjeta SD física disponible). Un método de conveniencia, isExternalStorageRemovable(), permite que las aplicaciones determinen si hay una tarjeta SD física.

    Administrador de paquetes

    Telefonía

    • El TelephonyManager agrega la constante NETWORK_TYPE_EVDO_B para especificar el tipo de red CDMA EvDo Rev B.
    • El nuevo método getPsc() muestra el código desordenado principal de la celda de entrega en una red de UMTS.

    Acceso nativo al ciclo de vida de la actividad en ventanas

    Android 2.3 expone un amplio conjunto de APIs a las aplicaciones que usan código nativo. Las clases de marcos de trabajo de interés para dichas aplicaciones incluyen:

    • NativeActivity es un nuevo tipo de clase de Activity, cuyas devoluciones de llamada de ciclo de vida se implementan directamente en código nativo. Un NativeActivity y su código nativo subyacente se ejecutan en el sistema al igual que otras actividades. Específicamente, se ejecutan en el proceso del sistema de la aplicación para Android y se ejecutan en el subproceso de IU principal de la aplicación. Además, reciben las mismas devoluciones de llamada de ciclo de vida que otras actividades.
    • La nueva clase InputQueue y la interfaz de devolución de llamada permite que el código nativo administre la cola de eventos.
    • La nueva interfaz SurfaceHolder.Callback2 permite que el código nativo administre un SurfaceHolder.
    • Los nuevos métodos takeInputQueue y takeSurface() en Window permiten que el código nativo administre eventos y plataformas.

    Si deseas obtener información completa para trabajar con código nativo o descargar el NDK, consulta la página del NDK de Android.

    Tiempo de ejecución de Dalvik

    Nuevos atributos y elementos del manifiesto

    • Se agregó un atributo xlargeScreens nuevo para el elemento <supports-screens> a fin de indicar si la aplicación admite factores de forma de pantalla extragrandes. Para obtener más información, consulta Compatibilidad con diferentes pantallas.
    • Valores nuevos para el atributo android:screenOrientation del elemento <activity>:
      • "reverseLandscape": La actividad desea tener la pantalla en orientación horizontal, girada en la dirección opuesta al modo horizontal normal.
      • "reversePortrait": La actividad desea tener la pantalla en orientación vertical, girada en la dirección opuesta al modo vertical normal.
      • "sensorLandscape": La actividad desea tener la pantalla en orientación horizontal, pero puede usar el sensor para cambiar la dirección a la que apunta.
      • "sensorPortrait": La actividad desea tener la pantalla en orientación vertical, pero puede usar el sensor para cambiar la dirección a la que apunta.
      • "fullSensor": La orientación se determina mediante un sensor de orientación físico: la pantalla rotará en función de cómo el usuario mueva el dispositivo. Esto permite cualquiera de las 4 rotaciones posibles, independientemente de lo que haga normalmente el dispositivo (por ejemplo, algunos dispositivos normalmente no usan la rotación de 180 grados).

    Permisos nuevos

    • com.android.permission.SET_ALARM: Permite que una aplicación transmita un intent a fin de establecer una alarma para el usuario. Una actividad que controla la acción de intent SET_ALARM debería requerir este permiso.
    • android.permission.USE_SIP: Permite que una aplicación use SIP API para realizar o recibir llamadas por Internet.
    • android.permission.NFC: Permite que una aplicación use NFC API para leer etiquetas NFC.

    Nuevas constantes de funciones

    La plataforma agrega varias funciones de hardware nuevas que los desarrolladores pueden declarar en los manifiestos de sus aplicaciones como obligatorias. Esto permite a los desarrolladores controlar cómo se filtra su aplicación cuando se publica en Google Play.

    Si quieres obtener información completa para declarar funciones y usarlas para filtrar, consulta la documentación de <uses-feature>.

    Informe de diferencias de las APIs

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

    Nivel de API

    La plataforma de Android 2.3 entrega una versión actualizada de la API de framework. A la API de Android 2.3 se le asigna un identificador de número entero, 9, 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 APIs presentadas en Android 2.3 en tu aplicación, debes compilarla con la biblioteca de Android que se proporciona en la plataforma de SDK de Android 2.3. Según tus necesidades, es posible que también debas agregar un atributo android:minSdkVersion="9" al elemento <uses-sdk> en el manifiesto de la aplicación. Si la aplicación está diseñada para ejecutarse solo en Android 2.3 y versiones posteriores, declarar el atributo evita que la aplicación se instale en versiones anteriores de la plataforma.

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