APIs de Android 4.0

Nivel de API: 14

Android 4.0 (ICE_CREAM_SANDWICH) es un lanzamiento importante de la plataforma que agrega una variedad de funciones nuevas para los usuarios y la desarrolladores. Además de todas las nuevas funciones y APIs que se analizan a continuación, Android 4.0 es una función lanzamiento de la plataforma porque incorpora el amplio conjunto de APIs y temas holográficos de Android 3.x a pantallas más pequeñas. Como desarrollador de apps, ahora tienes una sola plataforma y un marco de API unificado que te permite desarrollar y publicar tu aplicación con un único APK que proporciona una experiencia del usuario optimizada para teléfonos celulares, tablets y más, cuando se ejecuta la misma versión de Android: Android 4.0 (nivel de API 14) o una versión posterior

Para los desarrolladores, la plataforma Android 4.0 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 4.0, 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 nuevas APIs de Android 4.0.

APIs de redes sociales en el proveedor de contactos

Las APIs de contacto definidas por el proveedor de ContactsContract ampliadas para admitir nuevas funciones sociales, como un perfil personal para el propietario del dispositivo y la posibilidad de que los usuarios inviten a los contactos individuales a las redes sociales que estén instaladas en el dispositivo.

Perfil de usuario

Android ahora incluye un perfil personal que representa al propietario del dispositivo, según lo define el Tabla ContactsContract.Profile. Aplicaciones sociales que mantienen la identidad del usuario puede contribuir a los datos de perfil del usuario creando una nueva entrada ContactsContract.RawContacts en ContactsContract.Profile. Es decir, los contactos sin procesar que representan el dispositivo que el usuario No deben pertenecer a la tabla de contactos sin procesar tradicional definida por el URI ContactsContract.RawContacts. debes agregar un contacto sin procesar del perfil en la mesa en CONTENT_RAW_CONTACTS_URI. Sin procesar los contactos de esta tabla se agregan al único perfil visible para el usuario con la etiqueta "Yo".

Para agregar un nuevo contacto sin procesar para el perfil, se necesita la android.Manifest.permission#WRITE_PROFILE. Del mismo modo, para leer desde el perfil debes solicitar el permiso android.Manifest.permission#READ_PROFILE. Sin embargo, la mayoría de las aplicaciones no deberían necesitar leer el perfil de usuario, incluso cuando se aporten datos al perfil. Leer el perfil del usuario es un permiso sensible, y debes esperar que los usuarios escéptica de las aplicaciones que lo solicitan.

Intent de invitación

La acción de intent INVITE_CONTACT permite que una app para invocar una acción que indique que el usuario desea agregar un contacto a una red social. La app al recibir la aplicación, la utiliza para invitar al contacto especificado a esa red social. La mayoría de las apps estarán en el extremo receptor de esta operación. Por ejemplo, el la app de Personas integrada invoca el intent de invitación cuando el usuario selecciona "Agregar conexión" de una configuración que aparece en los detalles de contacto de una persona.

Para que tu app sea visible como en "Agregar conexión", haz lo siguiente: tu app debe proporcionar un adaptador de sincronización para sincronizar la información de contacto de tu red social. Luego, debes indicar al sistema que tu app responde al intent INVITE_CONTACT Agregando el atributo inviteContactActivity al archivo de configuración de sincronización de tu app, con un nombre completamente calificado de la actividad que el sistema debe iniciar cuando envía el intent de invitación. La actividad que se inicia luego puede recuperar el URI para el contacto en cuestión del directorio de la intent datos y realizar el trabajo necesario para invitar a ese contacto a la red o agregar a la persona a la las conexiones de los usuarios.

Fotos grandes

Android ahora admite fotos de alta resolución para contactos. Ahora, cuando insertas una foto en una contacto, el sistema lo procesa en una miniatura de 96 x 96 (como lo hizo anteriormente) y en “Foto visible” de 256 x 256 que se guarda en un nuevo almacén de fotos basado en archivos (las dimensiones exactas que que elija el sistema puede variar en el futuro). Puedes agregar una foto grande a un contacto colocando foto en la columna habitual PHOTO de un de datos, que el sistema procesará para mostrar la miniatura y la foto que correspondan registros.

Comentarios de uso de los contactos

Las nuevas APIs de ContactsContract.DataUsageFeedback te permiten hacer un seguimiento la frecuencia con la que el usuario utiliza determinados métodos para ponerse en contacto con las personas, por ejemplo, qué tan seguido utiliza cada número de teléfono o dirección de correo electrónico. Esta información ayuda a mejorar la clasificación de cada contacto. método asociado a cada persona y ofrecer mejores sugerencias para ponerse en contacto con cada una de ellas.

Proveedor de calendario

Las nuevas APIs de Calendar te permiten leer, agregar, modificar y borrar calendarios, eventos, asistentes, recordatorios y alertas, que se almacenan en el Proveedor de calendario.

Varias apps y widgets pueden usar estas APIs para leer y modificar eventos del calendario. Sin embargo, algunos de los casos de uso más atractivos son los adaptadores de sincronización que sincronizan el calendario del usuario desde otros servicios de calendario con el proveedor de calendario, a fin de ofrecer una ubicación unificada para todos los de los eventos del usuario. Los eventos del Calendario de Google, por ejemplo, se sincronizan con el proveedor de calendario a través de el adaptador de sincronización del Calendario de Google, que permite ver estos eventos con la versión desde la app de Calendario.

El modelo de datos para los calendarios y la información relacionada con los eventos en el Proveedor de calendario es definido por CalendarContract Todos los datos de calendario del usuario se almacenan Cantidad de tablas definidas por varias subclases de CalendarContract:

  • La tabla CalendarContract.Calendars contiene el ID específico del calendario información. Cada fila de esta tabla contiene los detalles de un solo calendario, como el nombre, el color, sincronizar información, etc.
  • La tabla CalendarContract.Events contiene información específica del evento. Cada fila de esta tabla contiene la información de un solo evento, como el título del evento, ubicación, hora de inicio, hora de finalización, etcétera. El evento puede ocurrir una vez o repetirse varias veces. Los asistentes, los recordatorios y las propiedades extendidas se almacenan en tablas separadas y Usa el elemento _ID del evento para vincularlo con este.
  • La tabla CalendarContract.Instances contiene la hora de inicio y finalización de casos de un evento. Cada fila de esta tabla representa un solo caso. Para eventos únicos hay una asignación uno a uno de instancias a eventos. En el caso de los eventos recurrentes, se agregan varias filas generarse automáticamente para que se correspondan con las múltiples ocurrencias de ese evento.
  • La tabla CalendarContract.Attendees contiene al asistente o invitado al evento. información. Cada fila representa un solo invitado a un evento. Especifica el tipo de huésped la persona y su respuesta al evento.
  • La tabla CalendarContract.Reminders contiene los datos de alerta/notificación. Cada fila representa una sola alerta para un evento. Un evento puede tener múltiples recordatorios. El número de los recordatorios por evento se especifican en MAX_REMINDERS, que establece el adaptador de sincronización que es propietario de ese calendario. Los recordatorios se especifican en minutos antes de la programado y especifica un método de alarma, por ejemplo, para usar una alerta, un correo electrónico o un SMS para recordar del usuario.
  • La tabla CalendarContract.ExtendedProperties contiene campos de datos opacos que usa el adaptador de sincronización. El proveedor no realiza ninguna acción con los elementos de esta tabla, excepto borrar cuando se borran los eventos relacionados.

Para acceder a los datos del calendario de un usuario con el proveedor de calendario, tu aplicación debe solicitar el permiso READ_CALENDAR (para acceso de lectura) WRITE_CALENDAR (para acceso de escritura)

Intención del evento

Si lo único que quieres hacer es agregar un evento al calendario del usuario, puedes usar un intent ACTION_INSERT con los datos definidos por Events.CONTENT_URI para iniciar una actividad en la aplicación Calendario que crea nuevos eventos. El uso del intent no requiere que permiso y puedes especificar los detalles del evento con los siguientes extras:

Proveedor de mensajes de voz

El nuevo proveedor de buzón de voz permite que las aplicaciones agreguen mensajes de voz al para presentar todos los mensajes de voz del usuario en una sola presentación visual. Por ejemplo: es posible que un usuario tenga varias fuentes de buzón de voz, como uno del proveedor de servicios del teléfono y otros de VoIP u otra voz alternativa de Google Cloud. Estas apps pueden usar las APIs del proveedor de mensajes de voz para agregar sus mensajes de voz al dispositivo. El Teléfono integrada luego presenta todos los mensajes de voz al usuario en una presentación unificada. Si bien la aplicación Teléfono del sistema es la única que puede leer todos los mensajes del buzón de voz, cada aplicación que proporciona mensajes de voz puede leer los que agregó al sistema (pero no puede leer mensajes de voz de otros servicios).

Dado que las API actualmente no permiten que aplicaciones de terceros lean todos los mensajes del buzón de voz desde el las únicas apps de terceros que deberían usar las APIs de buzón de voz son las que tienen entregar al usuario.

La clase VoicemailContract define el proveedor de contenido para el Creador de mensajes de voz. Las subclases VoicemailContract.Voicemails y VoicemailContract.Status proporcionan tablas en las que las apps pueden insertar datos del buzón de voz para almacenarlos en el dispositivo. Si deseas ver un ejemplo de una app de proveedor de buzón de voz, consulta la Proveedor de mensajes de voz Demostración.

Multimedia

En Android 4.0 se agregan varias API nuevas para aplicaciones que interactúan con contenido multimedia, como fotos, videos y música.

Efectos multimedia

Un nuevo framework de efectos multimedia te permite aplicar diversos efectos visuales a las imágenes y videos. Por ejemplo, los efectos de imagen te permiten corregir ojos rojos, convertir una imagen a escala de grises, ajusta el brillo, ajusta la saturación, rota una imagen, aplica un efecto de ojo de pez y mucho más. El sistema realiza el procesamiento de todos los efectos en la GPU para obtener el máximo rendimiento.

Para obtener el máximo rendimiento, los efectos se aplican directamente a las texturas OpenGL, por lo que tu aplicación debe tener un contexto OpenGL válido para poder usar las APIs de efectos. Las texturas a las que aplicas los efectos pueden provenir de mapas de bits, videos o incluso la cámara. Sin embargo, existen ciertas restricciones texturas deben cumplir con lo siguiente:

  1. Se deben vincular a una imagen de textura GL_TEXTURE_2D.
  2. Deben contener al menos un nivel de mipmaps

Un objeto Effect define un único efecto multimedia al que te puedes aplicar un marco de imagen. El flujo de trabajo básico para crear un Effect es el siguiente:

  1. Llama a EffectContext.createWithCurrentGlContext() desde tu contexto de OpenGL ES 2.0.
  2. Usa el EffectContext que se muestra para llamar a EffectContext.getFactory(), que muestra una instancia. de EffectFactory.
  3. Llama a createEffect() y pásale un nombre del efecto de @link android.media.effect.EffectFactory}, como EFFECT_FISHEYE o EFFECT_VIGNETTE.

Para ajustar los parámetros de un efecto, llama a setParameter() y pasa un nombre y un valor del parámetro. Cada tipo de efecto acepta parámetros diferentes, que se documentan con el nombre del efecto. Por ejemplo, EFFECT_FISHEYE tiene un parámetro para el scale de la distorsión.

Para aplicar un efecto en una textura, llama a apply() en la Effect y pasa la textura de entrada, el ancho y la altura, y el resultado. textura. La textura de entrada debe vincularse a una textura GL_TEXTURE_2D. imagen (por lo general, se hace llamando a glTexImage2D() función). Puedes proporcionar varios niveles de mipmaps. Si la textura de salida no se vinculó a una de textura, se vinculará automáticamente por el efecto como GL_TEXTURE_2D y con un nivel de mipmap (0), que tendrá el mismo como la entrada.

Se garantiza la compatibilidad con todos los efectos enumerados en EffectFactory. Sin embargo, algunos efectos adicionales disponibles de las bibliotecas externas no son compatibles con todos los dispositivos. por lo que primero debes verificar si el efecto deseado de la biblioteca externa es compatible llamando isEffectSupported()

Cliente de control remoto

El nuevo RemoteControlClient permite que los reproductores multimedia habiliten la reproducción. controles de acceso desde clientes de control remoto, como la pantalla de bloqueo del dispositivo. Los reproductores multimedia también pueden exponer información sobre el contenido multimedia que se está reproduciendo actualmente para mostrar en el control remoto, como la pista y la imagen del álbum.

Si quieres habilitar clientes de control remoto para tu reproductor multimedia, crea una instancia de RemoteControlClient con su constructor y pásale un PendingIntent que transmita ACTION_MEDIA_BUTTON. El intent también debe declarar el componente BroadcastReceiver explícito en tu app que controla el evento ACTION_MEDIA_BUTTON.

Para declarar las entradas de control multimedia que puede controlar el reproductor, debes llamar a setTransportControlFlags() en tu RemoteControlClient, que pasa un conjunto de marcas FLAG_KEY_MEDIA_*, como FLAG_KEY_MEDIA_PREVIOUS y FLAG_KEY_MEDIA_NEXT.

Luego, debes registrar tu RemoteControlClient y pasarla a MediaManager.registerRemoteControlClient(). Una vez registrado, el receptor de emisión que declaraste cuando creaste una instancia de RemoteControlClient recibirá ACTION_MEDIA_BUTTON eventos cuando se presiona un botón desde un control remoto. El intent que recibes incluye el KeyEvent de la tecla multimedia presionada, que puedes recuperar del intent con getParcelableExtra(Intent.EXTRA_KEY_EVENT).

Para mostrar información en el control remoto sobre el contenido multimedia que se reproduce, llama a editMetaData() y agrega metadatos al archivo multimedia que se muestra. RemoteControlClient.MetadataEditor Puedes proporcionar un mapa de bits para material gráfico multimedia, información numérica, como el tiempo transcurrido, e información de texto, como el título de la pista. Para Para obtener información sobre las claves disponibles, consulta las marcas METADATA_KEY_* en MediaMetadataRetriever.

Para ver una implementación de muestra, consulta el Reproductor de música aleatorio, que proporciona una lógica de compatibilidad que habilita el cliente de control remoto en Android 4.0 sin dejar de admitir dispositivos hasta la versión Android 2.1.

Reproductor multimedia

  • La transmisión de contenido multimedia en línea desde MediaPlayer ahora requiere el permiso INTERNET. Si usas MediaPlayer para Reproducir contenido de Internet, asegúrate de agregar INTERNET permiso en tu manifiesto; de lo contrario, la reproducción de contenido multimedia no funcionará a partir de Android 4.
  • setSurface() te permite definir un Surface para que se comporte como receptor de video.
  • setDataSource() te permite hacer lo siguiente: envía encabezados HTTP adicionales con tu solicitud, lo que puede ser útil para la transmisión en vivo de HTTP(S).
  • La transmisión en vivo HTTP(S) ahora respeta las cookies HTTP en todas las solicitudes.

Tipos de medios

Android 4.0 agrega compatibilidad con lo siguiente:

  • Protocolo de transmisión en vivo HTTP/HTTPS, versión 3
  • Codificación de audio AAC sin procesar ADTS
  • Imágenes WEBP
  • Video de Matroska

Para obtener más información, consulta Contenido multimedia compatible. Formatos

Cámara

La clase Camera ahora incluye APIs para detectar rostros y controlar áreas de enfoque y medición.

Detección de rostro

Las apps de cámara ahora pueden mejorar sus capacidades con las APIs de detección de rostro de Android, que no Solo detectan el rostro de un sujeto, pero también rasgos faciales específicos, como los ojos y la boca.

Para detectar rostros en tu aplicación de cámara, debes registrar un Camera.FaceDetectionListener llamando a setFaceDetectionListener(). Luego, puedes comenzar la superficie de la cámara y comienza a detectar rostros llamando a startFaceDetection().

Cuando detecta uno o más rostros en la escena de la cámara, llama a la devolución de llamada onFaceDetection() en tu implementación de Camera.FaceDetectionListener, que incluye un array de Objetos Camera.Face.

Una instancia de la clase Camera.Face proporciona información sobre lo siguiente: el rostro detectado, por ejemplo:

  • Un Rect que especifica los límites del rostro, en relación con la longitud de la cámara campo visual actual
  • Un número entero entre 1 y 100 que indica el grado de confianza con el que se encuentra el sistema de que el objeto es un rostro humano
  • Un ID único para que puedas hacer un seguimiento de varios rostros
  • Varios objetos Point que indican dónde están los ojos y la boca localizado

Nota: Es posible que la detección de rostro no sea compatible con algunos dispositivos por lo que debes verificar llamando a getMaxNumDetectedFaces() y asegurarte de que es mayor que cero. Además, es posible que algunos dispositivos no admitan la identificación de ojos y boca, en cuyo caso, esos campos en el objeto Camera.Face serán nulos.

Áreas de enfoque y medición

Las apps de cámara ahora pueden controlar las áreas que la cámara usa para enfocar y medir el blanco saldo y la exposición automática. Ambas funciones usan la nueva clase Camera.Area para especificar la región de la vista actual de la cámara que se debe enfocar o medir. Una instancia de la clase Camera.Area define los límites del área con un Rect y el peso del área, lo que representa el nivel de importancia de la en relación con otras áreas en consideración, con un número entero.

Antes de configurar un área de enfoque o un área de medición, debes llamar a getMaxNumFocusAreas() o getMaxNumMeteringAreas(), respectivamente. Si devuelve cero, entonces el dispositivo no es compatible con la función correspondiente.

Para especificar las áreas de enfoque o medición que deseas usar, simplemente llama a setFocusAreas() o setMeteringAreas(). Cada uno toma una List de objetos Camera.Area que indican las áreas que se deben considerar. para enfocar o medir. Por ejemplo, podrías implementar una función que permita al usuario establecer la enfoque. Para ello, toca un área de la vista previa, que luego traducirás a un objeto Camera.Area y solicitarás que la cámara se enfoque en esa área de la escena. El enfoque o la exposición en esa área se actualizará continuamente a medida que cambie la escena en el área.

Enfoque automático continuo para las fotos

Ahora puedes habilitar el enfoque automático continuo (CAF) cuando tomes fotos. Para habilitar CAF en tu App de cámara, pasar FOCUS_MODE_CONTINUOUS_PICTURE a setFocusMode(). Cuando esté todo listo para capturar una foto, llama a autoFocus(). Tu Camera.AutoFocusCallback recibe inmediatamente una devolución de llamada para indicar si se logró el enfoque. Para reanudar CAF después de recibir la devolución de llamada, debes llamar a cancelAutoFocus().

Nota: También se admite el enfoque automático continuo al capturar mediante FOCUS_MODE_CONTINUOUS_VIDEO, que se agregado en el nivel de API 9.

Otras funciones de la cámara

  • Mientras grabas un video, ahora puedes llamar a takePicture() para guardar una foto sin interrumpir la sesión de video. Antes de hacerlo, deberías llama a isVideoSnapshotSupported() para asegurarte de que el hardware lo respaldan.
  • Ahora puedes bloquear la exposición automática y el balance de blancos con setAutoExposureLock() y setAutoWhiteBalanceLock() para evitar estas propiedades cambien.
  • Ahora puedes llamar a setDisplayOrientation() mientras se ejecuta la vista previa de la cámara. Antes, se podía llamar así solo antes de iniciar la vista previa, pero ahora puede cambiar la orientación en cualquier momento.

Intents de transmisión de la cámara

  • Camera.ACTION_NEW_PICTURE: Esto indica que el usuario capturó una foto nueva. La app de Cámara integrada invoca este después de capturar una foto, y apps de cámara de terceros también deben transmitir este intent después de tomar una foto.
  • Camera.ACTION_NEW_VIDEO: Esto indica que el usuario capturó un video nuevo. La app de Cámara integrada invoca este después de que se graba un video, y las apps de cámara de terceros también deben transmitir este intent después de grabar un video.

Android Beam (NDEF Push con NFC)

Android Beam es una función nueva de NFC que te permite enviar mensajes NDEF de un dispositivo a otro (un proceso también conocido como “NDEF Push”). La transferencia de datos se inicia cuando dos Los dispositivos con Android compatibles con Android Beam se encuentran cerca (aproximadamente a 4 cm), generalmente con tocarse la espalda. Los datos dentro del mensaje NDEF pueden contener cualquier dato que desees compartir. entre dispositivos. Por ejemplo, la aplicación Personas comparte contactos, YouTube comparte videos y comparte URLs con Android Beam.

Para transmitir datos entre dispositivos con Android Beam, debes crear un NdefMessage que contenga la información que quieras compartir mientras tu actividad esté en curso en primer plano. Luego, debes pasar el NdefMessage al sistema en uno de dos. maneras:

En caso de que quieras ejecutar algún código específico una vez que el sistema haya enviado correctamente tu NDEF al otro dispositivo, puedes implementar NfcAdapter.OnNdefPushCompleteCallback y configurarlo con setNdefPushCompleteCallback(). El sistema y, luego, llama a onNdefPushComplete() cuando se entregue el mensaje.

En el dispositivo receptor, el sistema envía mensajes push NDEF de manera similar a lo que ocurre con NFC normal. rótulos nuevos rápidamente. El sistema invoca un intent con el elemento ACTION_NDEF_DISCOVERED. para iniciar una actividad, con una URL o un tipo de MIME configurado según el primer elemento NdefRecord de la NdefMessage. Para la actividad que quieres respondes, puedes declarar filtros de intents para las URLs o los tipos de MIME que son importantes para tu app. Para ver más para obtener más información sobre el envío de etiquetas, consulta la guía para desarrolladores de NFC.

Si deseas que tu NdefMessage lleve un URI, ahora puedes usar la función conveniente. el método createUri para construir un nuevo NdefRecord basado en una cadena o un objeto Uri. Si el URI es un formato especial que quieres que tu aplicación también reciba durante un evento de Android Beam, puedes debes crear un filtro de intents para tu actividad con el mismo esquema de URI para recibir el mensaje NDEF entrante.

También debes pasar un “registro de la aplicación para Android” con tu NdefMessage en para garantizar que tu aplicación maneje el mensaje NDEF entrante, incluso si se las aplicaciones filtran la misma acción de intent. Puedes crear un registro de aplicación para Android con llamando a createApplicationRecord(), pasándola el nombre del paquete de tu aplicación. Cuando el otro dispositivo recibe el mensaje NDEF con el registro de aplicación y varias aplicaciones contienen actividades que manejan el intent especificado, el sistema siempre entrega el mensaje a la actividad en tu aplicación (en función de la coincidencia registro de aplicación). Si el dispositivo de destino no tiene instalada tu aplicación actualmente, el usa el registro de aplicaciones de Android para iniciar Google Play y llevar al usuario a la aplicación para instalarla.

Si tu aplicación no usa las APIs de NFC para realizar mensajes push NDEF, Android proporciona un comportamiento predeterminado: cuando la aplicación se encuentra en primer plano en un dispositivo y Android Beam se invocado con otro dispositivo con Android, el otro dispositivo recibe un mensaje NDEF con un registro de la aplicación para Android que identifica tu aplicación. Si el dispositivo receptor tiene la la aplicación instalada, el sistema la inicia; si no está instalado, se abre Google Play y toma el usuario a tu aplicación para instalarla.

Puedes obtener más información sobre Android Beam y otras funciones de NFC en la guía para desarrolladores Conceptos básicos de NFC. Para ver un código de ejemplo con Android Beam, consulta la documentación de Android Demostración de Beam.

P2P Wi-Fi

Android ahora admite conexiones Wi-Fi entre pares (P2P) entre dispositivos con tecnología Android y Otros tipos de dispositivos (de acuerdo con el protocolo Wi-Fi DirectTM de Wi-Fi Alliance certificación) sin un hotspot ni conexión a Internet. El framework de Android ofrece un de APIs de Wi-Fi P2P que te permiten descubrir otros dispositivos y conectarte a ellos cuando cada uno de ellos sea compatible con P2P Wi-Fi, y luego se comunicarán a través de una conexión rápida a distancias mucho más largas que una Conexión Bluetooth.

Un paquete nuevo, android.net.wifi.p2p, contiene todas las APIs para realizar conexiones entre pares conexiones con Wi-Fi. La clase principal con la que debes trabajar es WifiP2pManager, que puedes adquirir llamando a getSystemService(WIFI_P2P_SERVICE). WifiP2pManager incluye APIs que te permiten hacer lo siguiente:

  • Inicializa tu aplicación para las conexiones P2P llamando a initialize()
  • Llama a discoverPeers() para descubrir dispositivos cercanos
  • Inicia una conexión P2P llamando a connect()
  • Y mucho más

También se necesitan otras interfaces y clases, como las siguientes:

  • La interfaz WifiP2pManager.ActionListener te permite recibir las devoluciones de llamadas cuando se realiza correctamente o falla una operación, como descubrir pares o conectarse a ellos.
  • La interfaz de WifiP2pManager.PeerListListener te permite recibir información sobre los pares descubiertos. La devolución de llamada proporciona un WifiP2pDeviceList, desde el cual puedes recuperar un objeto WifiP2pDevice para cada dispositivo dentro del alcance y obtener información como la siguiente: el nombre del dispositivo, la dirección, el tipo de dispositivo, las configuraciones de WPS que admite el dispositivo y mucho más.
  • La interfaz WifiP2pManager.GroupInfoListener te permite hacer lo siguiente: recibir información sobre un grupo P2P. La devolución de llamada proporciona un objeto WifiP2pGroup, que brinda información de grupo, como el propietario, el el nombre de la red y la frase de contraseña.
  • WifiP2pManager.ConnectionInfoListener te permite hacer lo siguiente: para recibir información sobre la conexión actual. La devolución de llamada proporciona un objeto WifiP2pInfo, que contiene información, por ejemplo, si se activó un grupo y quién es el propietario del grupo.

Para usar las API P2P Wi-Fi, tu app debe solicitar los siguientes permisos de usuario:

El sistema Android también transmite varias acciones diferentes durante ciertos eventos Wi-Fi P2P:

Consulta la documentación de WifiP2pManager para obtener más información. También mira la Demostración de P2P Wi-Fi en la aplicación de ejemplo.

Dispositivos Bluetooth de salud

Android ahora admite dispositivos con perfiles de salud Bluetooth, por lo que puedes crear aplicaciones que usen Bluetooth para comunicarse con dispositivos de salud compatibles con Bluetooth, como monitores de frecuencia cardíaca, medidores de sangre, termómetros y básculas.

Al igual que con los dispositivos de perfil A2DP y de auriculares comunes, debes llamar a getProfileProxy() con un BluetoothProfile.ServiceListener y el tipo de perfil HEALTH para establecer una conexión con el perfil. objeto de proxy.

Una vez que hayas adquirido el proxy de perfiles de salud (el BluetoothHealth (objeto), conectarse a dispositivos de salud vinculados y comunicarse con ellos implica el siguiente Clases de Bluetooth:

  • BluetoothHealthCallback: Debes extender esta clase e implementar el métodos de devolución de llamada para recibir actualizaciones sobre los cambios en el estado de registro de la aplicación y Estado del canal de Bluetooth.
  • BluetoothHealthAppConfiguration: Durante las devoluciones de llamada a tu BluetoothHealthCallback, recibirás una instancia de este objeto, que proporciona información de configuración sobre el dispositivo de salud Bluetooth disponible que debes usar para realizar varias operaciones, como iniciar y finalizar conexiones con las APIs de BluetoothHealth.

Para obtener más información sobre el uso del perfil de estado de Bluetooth, consulta la documentación de BluetoothHealth.

Accesibilidad

Android 4.0 mejora la accesibilidad para los usuarios con discapacidad visual con el nuevo modo de exploración táctil y las API extendidas que te permiten brindar más información sobre cómo ver contenido o servicios de accesibilidad avanzados.

Modo de exploración táctil

Ahora, los usuarios con pérdida de visión pueden explorar la pantalla tocando y arrastrando un dedo sobre el pantalla para escuchar descripciones de voz del contenido. Debido a que el modo de exploración táctil funciona como un cursor virtual, permite que los lectores de pantalla identifiquen el texto descriptivo de la misma manera que que los lectores pueden hacer cuando el usuario navega con un pad direccional o una bola de seguimiento, leyendo la información proporcionada de android:contentDescription y setContentDescription() con un "colocar el cursor" simulado para cada evento. Entonces: considera que debes proporcionar un texto descriptivo para las vistas de tu especialmente para ImageButton, EditText, ImageView y otros widgets que podrían no contener texto descriptivo texto.

Accesibilidad de las vistas

Para mejorar la información disponible para los servicios de accesibilidad, como los lectores de pantalla, puedes hacer lo siguiente: implementar nuevos métodos de devolución de llamada para eventos de accesibilidad en tus componentes View personalizados

Es importante tener en cuenta que el comportamiento del método sendAccessibilityEvent() cambió en Android. 4. Al igual que con la versión anterior de Android, cuando el usuario habilita los servicios de accesibilidad en el dispositivo. y se produce un evento de entrada, como un clic o colocar el cursor sobre un elemento, la vista respectiva recibe una llamada a sendAccessibilityEvent() Anteriormente, el implementación de sendAccessibilityEvent() inicializa un AccessibilityEvent y envíalo a AccessibilityManager. El nuevo comportamiento implica una devolución de llamada adicional métodos que permiten que la vista y sus elementos superiores agreguen más información contextual al evento:

  1. Cuando se invocan, los métodos sendAccessibilityEvent() y sendAccessibilityEventUnchecked() aplazan a onInitializeAccessibilityEvent().

    Es posible que las implementaciones personalizadas de View implementen onInitializeAccessibilityEvent() para adjuntar información de accesibilidad adicional a AccessibilityEvent, pero también debe llamar a la superimplementación para que proporcionan información predeterminada, como la descripción estándar del contenido, el índice de artículos y mucho más. Sin embargo, no debes agregar contenido de texto adicional en esta devolución de llamada, ya que eso sucede. a continuación.

  2. Una vez inicializado, el evento es uno de varios tipos que deben completarse con texto. información, la vista recibe una llamada a dispatchPopulateAccessibilityEvent(), que difiere a la onPopulateAccessibilityEvent() devolución de llamada.

    Por lo general, las implementaciones personalizadas de View deben implementar onPopulateAccessibilityEvent() para agregar más contenido de texto a AccessibilityEvent si falta el texto android:contentDescription insuficientes. Para agregar más texto descriptivo al AccessibilityEvent, llama a getText().add().

  3. En este punto, View pasa el evento hacia arriba en la jerarquía de vistas llamando a requestSendAccessibilityEvent() en el vista parental. Cada vista principal tiene la oportunidad de aumentar la información de accesibilidad agregando un AccessibilityRecord, hasta que En última instancia, llega a la vista raíz, que envía el evento al AccessibilityManager con sendAccessibilityEvent().

Además de los nuevos métodos anteriores, que son útiles para extender la clase View, también puedes interceptar estas devoluciones de llamada de eventos en cualquier View extendiendo AccessibilityDelegate y configurándolo en la vista con setAccessibilityDelegate() Cuando lo hagas, cada método de accesibilidad de la vista aplaza la llamada al método correspondiente en el delegado. Por ejemplo, cuando la vista recibe una llamada a onPopulateAccessibilityEvent(), la pasa al mismo método en View.AccessibilityDelegate. Cualquier método no manejado por el delegado se devuelven directamente a la vista para el comportamiento predeterminado. Esto te permite anular solo los métodos necesarios para cualquier vista determinada sin extender la clase View

Si quieres mantener la compatibilidad con versiones de Android anteriores a la 4.0 y, al mismo tiempo, ofrecer compatibilidad las nuevas APIs de accesibilidad, puedes hacerlo con la versión más reciente de la compatibilidad con v4 biblioteca (en Paquete de compatibilidad, r4) usando un conjunto de clases de utilidades que brinden las nuevas APIs de accesibilidad en un entorno retrocompatible el diseño de tu producto.

Servicios de accesibilidad

Si estás desarrollando un servicio de accesibilidad, la información sobre varios eventos de accesibilidad se expandió considerablemente para habilitar comentarios sobre accesibilidad más avanzados para los usuarios. En En particular, los eventos se generan en función de la composición de las vistas, lo que proporciona una mejor información de contexto y lo que permite que los servicios de accesibilidad recorran las jerarquías de vistas para obtener información adicional sobre estas y tratar casos especiales.

Si estás desarrollando un servicio de accesibilidad (como un lector de pantalla), puedes acceder información adicional de contenido y recorrer jerarquías de vistas con el siguiente procedimiento:

  1. Cuando recibas un AccessibilityEvent de una aplicación, ocurrirá lo siguiente: llama a AccessibilityEvent.getRecord() para recuperar un AccessibilityRecord específico (puede haber varios registros adjuntos al evento).
  2. Desde AccessibilityEvent o un AccessibilityRecord individual, puedes llamar a getSource() para recuperar un objeto AccessibilityNodeInfo.

    Un AccessibilityNodeInfo representa un solo nodo del contenido de la ventana en un formato que te permita consultar información de accesibilidad sobre ese el nodo de inicio de sesión. El objeto AccessibilityNodeInfo que muestra AccessibilityEvent describe la fuente del evento, mientras que la fuente de Un AccessibilityRecord describe el predecesor del evento. fuente.

  3. Con AccessibilityNodeInfo, puedes consultar información sobre ello, llama a getParent() o getChild() para desviar la vista jerárquica y hasta agregar vistas secundarias al nodo.

Para que tu aplicación se publique en el sistema como un servicio de accesibilidad, debe debes declarar un archivo de configuración XML que corresponda a AccessibilityServiceInfo. Para obtener más información sobre cómo crear un servicio de accesibilidad, consulta AccessibilityService y SERVICE_META_DATA para obtener información sobre la configuración de XML.

Otras APIs de accesibilidad

Si te interesa el estado de accesibilidad del dispositivo, AccessibilityManager tiene algunas APIs nuevas, como las siguientes:

Servicios de corrector ortográfico

Un nuevo marco de trabajo del corrector ortográfico permite que las aplicaciones creen correctores ortográficos de una manera similar a la del framework de métodos de entrada (para IME). Para crear un nuevo corrector ortográfico, debes implementar un servicio que extiende SpellCheckerService y extiende la clase SpellCheckerService.Session para proporcionar sugerencias ortográficas según en el texto proporcionado por los métodos de devolución de llamada de la interfaz. En los métodos de devolución de llamada SpellCheckerService.Session, debes mostrar el sugerencias ortográficas como objetos SuggestionsInfo.

Las aplicaciones con un servicio de corrector ortográfico deben declarar el permiso BIND_TEXT_SERVICE según lo requiera el servicio. El servicio también debe declarar un filtro de intents con <action android:name="android.service.textservice.SpellCheckerService" /> como la acción del intent y debe Incluye un elemento <meta-data> que declara la información de configuración para el hechizo. de verificación.

Ver la muestra del servicio de corrector ortográfico ejemplo Spell Checker Client para ver el código de ejemplo.

Motores de texto a voz

Las APIs de texto a voz (TTS) de Android se han ampliado considerablemente para permitir que las aplicaciones implementar más fácilmente motores de TTS personalizados, mientras que las aplicaciones que desean usar un motor de TTS tienen un algunas APIs nuevas para seleccionar un motor.

Usar motores de texto a voz

En versiones anteriores de Android, podías usar la clase TextToSpeech. para realizar operaciones de texto a voz (TTS) con el motor de TTS proporcionado por el sistema o definir una motor personalizado con setEngineByPackageName(). En Android 4.0, el método setEngineByPackageName() se obsoleto y ahora puedes especificar el motor que se usará con un nuevo constructor TextToSpeech que acepte el nombre del paquete de un motor de TTS.

También puedes consultar los motores de TTS disponibles con getEngines(). Este método muestra una lista de objetos TextToSpeech.EngineInfo, que incluyen metadatos, como el el ícono, la etiqueta y el nombre del paquete.

Cómo compilar motores de texto a voz

Antes, los motores personalizados requerían que se compilara con un encabezado nativo sin documentar. . En Android 4.0, existe un conjunto completo de APIs de framework para compilar motores de TTS.

La configuración básica requiere una implementación de TextToSpeechService responde al intent INTENT_ACTION_TTS_SERVICE. El El trabajo principal para un motor de TTS se realiza durante la devolución de llamada onSynthesizeText() en un servicio. que extiende TextToSpeechService. El sistema entrega este método dos objetos:

  • SynthesisRequest: contiene varios datos, incluido el texto que se sintetizar, la configuración regional, la velocidad y el tono de voz.
  • SynthesisCallback: Es la interfaz mediante la cual el motor de TTS entrega los datos de voz resultantes como una transmisión de audio. Primero, el motor debe llamar a start() para indicar que está listo para enviarse. el audio, y luego llamar a audioAvailable(), los datos de audio en un búfer de bytes. Una vez que el motor pase todo el audio por el llama a done().

Ahora que el framework admite una verdadera API para crear motores de TTS, la compatibilidad con el código nativo se quitó la implementación. Busca una entrada de blog sobre una capa de compatibilidad que puedes usar para convertir tus antiguos motores de TTS al nuevo framework.

Para ver un ejemplo de un motor de TTS con las nuevas APIs, consulta la app de ejemplo de Motor de texto a voz.

Uso de red

Android 4.0 ofrece a los usuarios una visibilidad precisa de la cantidad de datos de red que utilizan sus aplicaciones. La app de Configuración ofrece controles que permiten a los usuarios administrar y establecer límites para el uso de datos de red incluso inhabilitar el uso de datos en segundo plano para apps individuales. Para evitar que los usuarios inhabiliten tus el acceso de la app a los datos en segundo plano, debes desarrollar estrategias de forma eficiente y ajustar el uso según el tipo de conexión disponible.

Si tu aplicación realiza muchas transacciones de red, debes proporcionar una configuración de usuario que Permiten que los usuarios controlen los hábitos relacionados con los datos de tu app; por ejemplo, la frecuencia con la que esta sincroniza datos, si realizar cargas y descargas solo cuando el dispositivo esté conectado a Wi-Fi, ya sea para usar datos en roaming, etc. de acceso a los datos disponibles, es mucho menos probable que los usuarios inhabiliten el acceso de tu app a los datos cuando están cerca de sus límites porque, en cambio, pueden controlar con precisión la cantidad de datos que usa tu app. Si proporcionas una actividad de preferencia con esta configuración, debes incluirla en su manifiesto la declaración un filtro de intents para ACTION_MANAGE_NETWORK_USAGE acción. Por ejemplo:

<activity android:name="DataPreferences" android:label="@string/title_preferences">
    <intent-filter>
       <action android:name="android.intent.action.MANAGE_NETWORK_USAGE" />
       <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

Este filtro de intents le indica al sistema que esta es la actividad que controla tu el uso de datos por parte de la aplicación. Por lo tanto, cuando el usuario inspeccione cuántos datos usa tu aplicación desde la App de Configuración, una herramienta de “Ver la configuración de la aplicación” está disponible que inicia tu de preferencias para que el usuario pueda definir mejor la cantidad de datos que usa tu app.

Además, ten en cuenta que getBackgroundDataSetting() ahora es obsoleto y siempre muestra true; en su lugar, usa getActiveNetworkInfo(). Antes de intentar usar cualquier red transacciones, siempre debes llamar a getActiveNetworkInfo() para obtener el NetworkInfo que representa la red actual y consultar isConnected() para verificar si el dispositivo tiene una conexión. Luego, puedes verificar otras propiedades de conexión, como si el dispositivo está en roaming o que se conecte a Wi-Fi.

Enterprise

Android 4.0 amplía las capacidades de las aplicaciones empresariales con las siguientes funciones.

Servicios de VPN

El nuevo VpnService permite que las aplicaciones compilen su propia VPN (Virtual privada), que se ejecuta como Service. Un servicio de VPN crea una interfaz para un red virtual con su propia dirección y reglas de enrutamiento, y realiza todas las lecturas y escrituras con un descriptor de archivos.

Para crear un servicio de VPN, usa VpnService.Builder, que te permite especificar. como la dirección de red, el servidor DNS, la ruta de red y mucho más. Cuando se complete, puedes establecer llamando a establish(), que muestra un ParcelFileDescriptor.

Debido a que un servicio de VPN puede interceptar paquetes, hay implicaciones de seguridad. Por lo tanto, si implementar VpnService, tu servicio debe requerir el BIND_VPN_SERVICE para garantizar que solo el sistema pueda vincularse a él (solo se otorga este permiso al sistema; las aplicaciones no pueden solicitarlo). Luego, para usar el servicio de VPN, los usuarios deben habilitarlo manualmente en la configuración del sistema.

Políticas de dispositivo

Las aplicaciones que administran las restricciones de dispositivos ahora pueden inhabilitar la cámara con setCameraDisabled() y la propiedad USES_POLICY_DISABLE_CAMERA (se aplica con un elemento <disable-camera /> en el archivo de configuración de la política).

Administración de certificados

La nueva clase KeyChain proporciona APIs que te permiten importar y acceder en el almacén de claves del sistema. Los certificados agilizan la instalación de ambos clientes. certificados (para validar la identidad del usuario) y certificados de la autoridad certificadora (para verificar la identidad del servidor). Las aplicaciones como los navegadores web o los clientes de correo electrónico pueden acceder a la versión certificados para autenticar usuarios en los servidores. Consulta la KeyChain documentación para obtener más información.

Sensores de dispositivos

Se agregaron dos tipos de sensores nuevos en Android 4.0:

  • TYPE_AMBIENT_TEMPERATURE: Un sensor de temperatura que proporciona la temperatura ambiente (de la habitación) en grados Celsius.
  • TYPE_RELATIVE_HUMIDITY: un sensor de humedad que proporciona la la humedad relativa del ambiente (habitación) como porcentaje.

Si un dispositivo tiene sensores TYPE_AMBIENT_TEMPERATURE y TYPE_RELATIVE_HUMIDITY, puedes usarlos para calcular el punto de condensación y la humedad absoluta.

El sensor de temperatura anterior, TYPE_TEMPERATURE, se ha obsoleto. Debes usar el sensor TYPE_AMBIENT_TEMPERATURE en su lugar.

Además, los tres sensores sintéticos de Android han mejorado mucho, por lo que ahora tienen menos latencia y una salida más fluida. Estos sensores incluyen el sensor de gravedad (TYPE_GRAVITY), el sensor del vector de rotación (TYPE_ROTATION_VECTOR) y el sensor de aceleración lineal (TYPE_LINEAR_ACCELERATION). Los sensores mejorados dependen del giroscopio para mejorar su salida, de modo que los sensores solo aparezcan en dispositivos que tengan giroscopio.

Barra de acciones

Se actualizó ActionBar para admitir varios comportamientos nuevos. Más probable Lo más importante es que el sistema administra correctamente el tamaño y la configuración de la barra de acciones cuando se ejecuta en pantallas más pequeñas para proporcionar una experiencia del usuario óptima en todos los tamaños de pantalla. Por ejemplo: cuando la pantalla es angosta (como cuando un teléfono celular se encuentra en orientación vertical), la barra de acciones las pestañas de navegación aparecen en una “barra apilada”, que aparece justo debajo de la barra de acciones principal. Puedes habilitar la “barra de acciones dividida”, que coloca todos los elementos de acción en una barra separada en la parte inferior de la pantalla cuando es angosta.

Barra de acciones dividida

Si tu barra de acciones incluye varios elementos de acción, no todos caben en la barra de acciones de una pantalla estrecha, de modo que el sistema coloque más de ellas en el menú ampliado. Sin embargo, Android 4.0 te permite habilitar la “barra de acciones dividida” para que aparezcan más elementos de acción en la pantalla de forma barra separada en la parte inferior de la pantalla. Para habilitar la barra de acciones dividida, agrega android:uiOptions con "splitActionBarWhenNarrow" a tu <application> etiquetar o etiquetas <activity> individuales en tu archivo de manifiesto. Cuando se habilite, el sistema agregará una barra adicional en la parte inferior de pantalla para todos los elementos de acción cuando la pantalla sea angosta (no aparecerá ningún elemento de acción en la pantalla barra de acciones).

Si quieres usar las pestañas de navegación que proporcionan las APIs de ActionBar.Tab, haz lo siguiente: pero no necesitas la barra de acciones principal en la parte superior (sería mejor que solo aparezcan las pestañas en la parte superior) y, luego, habilita la barra de acciones dividida como se describió anteriormente y también llamar a setDisplayShowHomeEnabled(false) para inhabilitar la ícono de la aplicación en la barra de acciones. Como no queda nada en la barra de acciones principal, desaparece; todo lo que queda a la izquierda son las pestañas de navegación en la parte superior y los elementos de acción en parte inferior de la pantalla.

Estilos de la barra de acciones

Si deseas aplicar un estilo personalizado a la barra de acciones, puedes usar las nuevas propiedades de estilo backgroundStacked y backgroundSplit para aplicar un fondo. drawable o color a la barra apilada y la barra dividida, respectivamente. También puedes establecer estos estilos en entorno de ejecución con setStackedBackgroundDrawable() y setSplitBackgroundDrawable().

Proveedor de acciones

La nueva clase ActionProvider te permite crear un controlador especializado para elementos de acción. Un proveedor de acciones puede definir una vista de acción, un comportamiento de acción predeterminado y un submenú. para cada elemento de acción al que está asociado. Cuando quieras crear un elemento de acción que tenga comportamientos dinámicos (como una vista de acción variable, una acción predeterminada o un submenú), extender ActionProvider es una buena solución para crear un componente reutilizable, en lugar de controlar las diversas transformaciones de elementos de acción en tu fragmento o actividad

Por ejemplo, ShareActionProvider es una extensión de ActionProvider que facilita el "uso compartido". desde la barra de acciones. En lugar de usar elemento de acción tradicional que invoca el intent ACTION_SEND, puedes usar este proveedor de acciones para presentar una vista de acción con una lista desplegable de aplicaciones que manejan el intent ACTION_SEND. Cuando el usuario selecciona una aplicación para usar para la acción, ShareActionProvider recuerda esa selección y la proporciona en la vista de acción para acceder más rápido al uso compartido con esa app.

Para declarar un proveedor de acciones para un elemento de acción, incluye android:actionProviderClass. en el elemento <item> del menú de opciones de tu actividad, con el nombre de clase de la acción. como el valor del proveedor. Por ejemplo:

<item android:id="@+id/menu_share"
      android:title="Share"
      android:showAsAction="ifRoom"
      android:actionProviderClass="android.widget.ShareActionProvider" />

En el onCreateOptionsMenu() de tu actividad de devolución de llamada, recupera una instancia del proveedor de acciones desde el elemento de menú y establece la intent:

Kotlin

override fun onCreateOptionsMenu(menu: Menu): Boolean {
    menuInflater.inflate(R.menu.options, menu)
    val shareActionProvider = menu.findItem(R.id.menu_share)?.actionProvider as? ShareActionProvider
    // Set the share intent of the share action provider.
    shareActionProvider?.setShareIntent(createShareIntent())
    ...
    return super.onCreateOptionsMenu(menu)
}

Java

public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.options, menu);
    ShareActionProvider shareActionProvider =
          (ShareActionProvider) menu.findItem(R.id.menu_share).getActionProvider();
    // Set the share intent of the share action provider.
    shareActionProvider.setShareIntent(createShareIntent());
    ...
    return super.onCreateOptionsMenu(menu);
}

Para ver un ejemplo con ShareActionProvider, consulta ActionBarShareActionProviderActivity en ApiDemos.

Vistas de acción que se pueden contraer

Los elementos de acción que proporcionan una vista de acción ahora pueden alternar entre su estado de vista de acción y el estado de elemento de acción tradicional. Anteriormente, solo se admitía SearchView se puede contraer cuando se usa como vista de acción, pero ahora puede agregar una vista de acción para cualquier elemento de acción y para alternar entre el estado expandido (la vista de acción es visible) y el estado contraído (el elemento de acción es visibles).

Para declarar que un elemento de acción que contiene una vista de acción es contraíble, incluye la marca “collapseActionView" en el atributo android:showAsAction del elemento <item> en el archivo en formato XML del menú.

Para recibir devoluciones de llamada cuando una vista de acción cambie entre expandida y contraída, registra un instancia de MenuItem.OnActionExpandListener con el MenuItem respectivo llamando a setOnActionExpandListener(). Por lo general, debes hacerlo durante la devolución de llamada a onCreateOptionsMenu().

Para controlar una vista de acción que se puede contraer, puedes llamar a collapseActionView() y expandActionView() en el MenuItem respectivo.

Cuando creas una vista de acción personalizada, también puedes implementar la nueva interfaz CollapsibleActionView para recibir devoluciones de llamada cuando la vista se expande y contraída.

Otras APIs para la barra de acciones

  • setHomeButtonEnabled() te permite especificar si el ícono o logotipo se comporta como un botón para navegar a la página principal o “arriba” (pasa “true” para que se comporte como un botón).
  • setIcon() y setLogo() te permiten definir el ícono o el logotipo de la barra de acciones durante el tiempo de ejecución.
  • Fragment.setMenuVisibility() te permite habilitar o inhabilita la visibilidad de los elementos del menú de opciones declarados por el fragmento. Esto es útil si el el fragmento se agregó a la actividad, pero no es visible, por lo que los elementos del menú deben estar oculto.
  • FragmentManager.invalidateOptionsMenu() te permite invalidar el menú de opciones de la actividad durante varios estados del ciclo de vida del fragmento en las que el uso del método equivalente de Activity podría no estar disponible.

Interfaz de usuario y vistas

Android 4.0 presenta una variedad de vistas nuevas y otros componentes de la IU.

GridLayout

GridLayout es un nuevo grupo de vistas que ubica las vistas secundarias en una forma rectangular cuadrícula. A diferencia de TableLayout, GridLayout se basa en una de datos y no usa vistas intermedias, como filas de la tabla, para proporcionar estructura. En su lugar, los campos secundarios especifican las filas y columnas que deben ocupar (las celdas pueden abarcar varias filas o columnas) y, de forma predeterminada, se disponen de manera secuencial en las filas y columnas de la cuadrícula. La orientación GridLayout determina si los elementos secundarios secuenciales son de forma predeterminada horizontal o vertical. El espacio entre los niños puede especificarse mediante instancias de la nueva vista Space o estableciendo los parámetros de margen relevantes sobre los niños.

Ver ApiDemos para las muestras con GridLayout.

Vista de textura

TextureView es una vista nueva que te permite mostrar una transmisión de contenido, como como un video o una escena de OpenGL. Aunque es similar a SurfaceView, TextureView es único en el sentido de que se comporta como una vista normal, en lugar de crear una ventana separada, por lo que puedes tratarla como a cualquier otro objeto View. Por ejemplo: puedes aplicar transformaciones o animarlas con ViewPropertyAnimator. ajustar su opacidad con setAlpha().

Ten en cuenta que TextureView solo funciona dentro de una ventana acelerada por hardware.

Para obtener más información, consulta la documentación de TextureView.

Cambiar widget

El nuevo widget Switch es un botón de activación de dos estados que los usuarios pueden arrastrar a uno (o simplemente presiona) para alternar una opción entre dos estados.

Puedes usar los atributos android:textOn y android:textOff para especificar el texto aparezca en el interruptor cuando esté activado o desactivado. El atributo android:text también te permite colocar una etiqueta junto al interruptor.

Para ver una muestra de cómo usar interruptores, consulta el archivo de diseño switches.xml y los Interruptores correspondientes .

Android 3.0 introdujo PopupMenu para crear menús contextuales cortos que se destacan en el punto de anclaje que especifiques (generalmente, en el punto del elemento seleccionado). Android 4.0 extiende PopupMenu con algunas funciones útiles:

Preferencias

Una nueva clase abstracta TwoStatePreference sirve de base para que ofrecen una opción de selección de dos estados. El nuevo SwitchPreference es una extensión de TwoStatePreference que proporciona un widget de Switch en la de preferencias para permitir que los usuarios activen o desactiven un parámetro sin tener que abrir una ventana pantalla o diálogo de preferencias. Por ejemplo, la aplicación de Configuración usa un SwitchPreference para la configuración de Wi-Fi y Bluetooth.

Temas del sistema

El tema predeterminado para todas las aplicaciones orientadas a Android 4.0 (estableciendo targetSdkVersion o minSdkVersion a “14" o superior) ahora es el "dispositivo predeterminado" tema: Theme.DeviceDefault. Puede ser el tema Holo oscuro o un tema oscuro diferente definido por el dispositivo específico.

Se garantiza que la familia de temas Theme.Holo no cambiará. de un dispositivo a otro cuando se ejecuta la misma versión de Android. Si explícitamente aplicar cualquiera de los temas Theme.Holo a tus actividades, puedes ten la seguridad de que estos temas no cambiarán de personaje en diferentes dispositivos dentro del mismo versión de la plataforma.

Si deseas que tu app se integre con el tema general del dispositivo (por ejemplo, cuando se crean diferentes OEM proporcionar diferentes temas predeterminados para el sistema), debes aplicar temas de la familia Theme.DeviceDefault de forma explícita.

Botón del menú de opciones

A partir de Android 4.0, notarás que los teléfonos celulares ya no requieren un botón de hardware de menú. Sin embargo, no es necesario que te preocupes por esto si tu aplicación existente proporciona un menú de opciones y espera que haya un Botón de menú Para garantizar que las apps existentes sigan funcionando como se espera, el sistema proporciona el botón de menú en pantalla para las aplicaciones diseñadas para versiones anteriores de Android.

Para obtener la mejor experiencia del usuario, las apps nuevas y actualizadas deben usar ActionBar para brindar acceso a los elementos del menú y establecer targetSdkVersion como "14" para aprovechar los comportamientos predeterminados del framework más recientes.

Controles para la visibilidad de la IU del sistema

Desde los inicios de Android, el sistema ha administrado un componente de IU conocido como el estado barra, que se encuentra en la parte superior de los teléfonos celulares para brindar información, como el indicador, hora, notificaciones, etc. Android 3.0 agregó la barra del sistema para tablets. en la parte inferior de la pantalla para proporcionar los controles de navegación del sistema (Inicio, Atrás, etc.) y también una interfaz para elementos que tradicionalmente proporcionaba la barra de estado. En Android 4.0, el sistema proporciona un nuevo tipo de IU de sistema llamada barra de navegación. Tú podría considerar que la barra de navegación es una versión reajustada de la barra del sistema, diseñada para móviles, ya que proporciona controles de navegación para los dispositivos que no tienen equivalentes de hardware para navegar por el sistema, pero excluye las la IU de notificaciones y los controles de configuración de la barra del sistema. Como tal, un dispositivo que proporcione la navegación también tiene la barra de estado en la parte superior.

Hasta el día de hoy, puedes ocultar la barra de estado en teléfonos celulares con la marca FLAG_FULLSCREEN. En Android 4.0, las APIs que controlan Se actualizó la visibilidad de la barra del sistema para reflejar mejor el comportamiento de ambas. y la barra de navegación:

  • La marca SYSTEM_UI_FLAG_LOW_PROFILE reemplaza a la marca STATUS_BAR_HIDDEN. Cuando se establece, esta marca habilita el "perfil bajo" para la barra del sistema o barra de navegación. Los botones de navegación atenuados y otros elementos de la barra del sistema también se ocultan. Habilitando Esto es útil para crear juegos más envolventes sin distracciones para la navegación del sistema. botones.
  • La marca SYSTEM_UI_FLAG_VISIBLE reemplaza a la marca STATUS_BAR_VISIBLE para solicitar que la barra del sistema o de navegación sea visible.
  • El SYSTEM_UI_FLAG_HIDE_NAVIGATION es una nueva marca que solicita la barra de navegación se oculta por completo. Ten en cuenta que esta opción solo funciona para la barra de navegación. utilizado por algunos teléfonos (no oculta la barra del sistema en tablets). La navegación vuelve a verse en cuanto el sistema recibe la entrada del usuario. Por eso, este modo es útil principalmente para la reproducción de video u otros casos en los que se necesita toda la pantalla, pero la entrada del usuario es no es necesario.

Puedes establecer cada una de estas marcas para la barra del sistema y la barra de navegación llamando a setSystemUiVisibility() en cualquier vista de tu actividad. El el administrador de ventanas combina (con el operador O) todas las marcas de todas las vistas de tu ventana y aplicarlos a la IU del sistema siempre que la ventana tenga foco de entrada. Cuando tu ventana pierde datos (el usuario sale de la app o aparece un diálogo), las marcas dejan de tener efecto. Del mismo modo, si quitas esas vistas de la jerarquía de vistas, ya no se aplicarán sus marcas.

Para sincronizar otros eventos en tu actividad con cambios de visibilidad en la IU del sistema (por ejemplo, si se oculta la barra de acciones o con otros controles de la IU cuando la IU del sistema se oculta), debes registrar un View.OnSystemUiVisibilityChangeListener para recibir una notificación cuando la visibilidad de la barra del sistema o de la navegación.

Consulta el OverscanActivity para ver una demostración de las diferentes opciones de la IU del sistema.

Marco de trabajo de entrada

Android 4.0 agrega compatibilidad con eventos de desplazamiento del cursor y nuevos eventos de la pluma stylus y el botón del mouse.

Eventos de colocar el cursor sobre un elemento

La clase View ahora admite el desplazamiento para permitir interacciones más enriquecedoras mediante el uso de dispositivos de puntero (como un mouse u otros dispositivos que controlen el cursor).

Para recibir eventos de colocar el cursor sobre una vista, implementa View.OnHoverListener y regístralo con setOnHoverListener(). Cuando se coloca el cursor sobre en la vista, tu objeto de escucha recibe una llamada a onHover() y proporciona el View recibió el evento y un MotionEvent que describe el tipo de evento de colocar el cursor sobre un elemento que ocurrieron. El evento de colocar el cursor sobre un elemento puede ser uno de los siguientes:

Tu View.OnHoverListener debe mostrar un valor verdadero desde onHover() si controla el evento de desplazamiento. Si el El objeto de escucha muestra un valor falso, y el evento de desplazamiento se enviará a la vista principal como de costumbre.

Si tu aplicación usa botones u otros widgets que cambian su apariencia en función del estado actual, ahora puedes usar el atributo android:state_hovered en un elemento de diseño de lista de estados para Proporcionan un elemento de diseño de fondo diferente cuando se coloca el cursor sobre la vista.

Para ver una demostración de los nuevos eventos de colocar el cursor sobre un elemento, consulta la clase Colocar el cursor sobre un elemento en ApiDemos.

Eventos de la pluma stylus y el botón del mouse

Android ahora proporciona APIs para recibir entradas de un dispositivo de entrada de pluma stylus, como un digitalizador periférico de la tablet o una pantalla táctil compatible con la pluma stylus.

La entrada de la pluma stylus funciona de manera similar a las entradas táctiles o del mouse. Cuando la pluma stylus está en contacto Con el digitalizador, las aplicaciones reciben eventos táctiles tal como lo harían cuando se usa un dedo para toca la pantalla. Cuando la pluma stylus se coloca sobre el digitalizador, las aplicaciones reciben del mismo modo que lo harían cuando el puntero del mouse se moviera por la pantalla cuando no se usaran botones los botones.

Tu aplicación puede distinguir entre entrada de dedo, mouse, pluma stylus y borrador consultando la “tipo de herramienta” asociada con cada puntero en una MotionEvent mediante getToolType(). Los tipos de herramientas definidos actualmente son TOOL_TYPE_UNKNOWN, TOOL_TYPE_FINGER, TOOL_TYPE_MOUSE, TOOL_TYPE_STYLUS y TOOL_TYPE_ERASER. Cuando consultas el tipo de herramienta, tu aplicación puedes optar por controlar la entrada de la pluma stylus de diferentes maneras respecto de la entrada con el dedo o el mouse.

Tu aplicación también puede consultar qué botones del mouse o de la pluma stylus se presionan estado" de un objeto MotionEvent con getButtonState(). Los estados del botón definidos actualmente son BUTTON_PRIMARY, BUTTON_SECONDARY, BUTTON_TERTIARY, BUTTON_BACK y BUTTON_FORWARD. Para tu comodidad, los botones para ir atrás y avanzar del mouse son se asigna automáticamente a las claves KEYCODE_BACK y KEYCODE_FORWARD. Tu aplicación puede controlar estas claves para admitir botón del mouse basada en la navegación hacia atrás y adelante.

Además de medir con precisión la posición y la presión de un contacto, se pueden introducir también informan la distancia entre la punta de la pluma stylus y el digitalizador, el ángulo de inclinación de la pluma stylus, y el ángulo de orientación de la pluma stylus. Tu aplicación puede consultar esta información usando getAxisValue() con los códigos de eje AXIS_DISTANCE, AXIS_TILT y AXIS_ORIENTATION.

Para ver una demostración de los tipos de herramientas, los estados de los botones y los nuevos códigos de los ejes, consulta TouchPaint en ApiDemos.

Propiedades

La nueva clase Property proporciona una manera rápida, eficiente y fácil de especificar un en cualquier objeto que permita a los llamadores establecer/obtener valores de forma genérica en los objetos de destino. También permite la funcionalidad de pasar referencias de campo/método y permite que el código establezca/obtenga valores de la propiedad sin conocer los detalles de los campos o métodos.

Por ejemplo, si quieres establecer el valor del campo bar en el objeto foo, debes antes hicieron esto:

Kotlin

foo.bar = value

Java

foo.bar = value;

Si deseas llamar al método set para un campo privado subyacente bar, previamente usarías haz lo siguiente:

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

Sin embargo, si deseas pasar la instancia de foo y hacer que algún otro código establezca la bar, no hay forma de hacerlo antes de Android 4.0.

Con la clase Property, puedes declarar un Property. el objeto BAR en la clase Foo para que puedas establecer el campo en la instancia foo de la clase Foo de la siguiente manera:

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

La clase View ahora aprovecha la clase Property para te permiten establecer varios campos, como las propiedades de transformación que se agregaron en Android 3.0 (ROTATION, ROTATION_X, TRANSLATION_X, etc.).

La clase ObjectAnimator también usa Property. por lo que puedes crear un ObjectAnimator con un Property, que es más rápido, eficiente y más seguro de tipos que el basado enfoque.

Aceleración de hardware

A partir de Android 4.0, la aceleración de hardware para todas las ventanas está habilitada de forma predeterminada si tu aplicación configuró targetSdkVersion o minSdkVersion a “14" o una versión posterior. La aceleración de hardware genera animaciones más fluidas, desplazamiento, así como un mejor rendimiento y respuesta a la interacción del usuario.

Si es necesario, puedes inhabilitar manualmente la aceleración de hardware con hardwareAccelerated. para elementos <activity> individuales o el <application> . Como alternativa, puedes inhabilitar la aceleración de hardware para vistas individuales llamando a setLayerType(LAYER_TYPE_SOFTWARE).

Para obtener más información sobre la aceleración de hardware, incluida una lista de dibujos no admitidos consulta la documentación de Hardware Aceleración.

Cambios de JNI

En versiones anteriores de Android, las referencias locales de JNI no eran controladores indirectos. Android usado como punteros directos. Esto no fue un problema mientras el recolector de elementos no utilizados no moviera objetos, pero parecía funcionar porque posibilitaba la escritura de códigos con errores. En Android 4.0, el sistema ahora usa referencias indirectas para detectar estos errores.

Los pormenores de las referencias locales de JNI se describen en la sección "Referencias locales y globales". en Sugerencias de JNI. En Android 4.0, CheckJNI se mejoró para detectar estos errores. Mira el Blog para desarrolladores de Android para conocer una próxima publicación sobre errores comunes con referencias de JNI y cómo puedes corregirlos.

Este cambio en la implementación de JNI solo afecta a las apps orientadas a Android 4.0 configurando targetSdkVersion o minSdkVersion por “14" o una versión posterior. Si fijaste estos atributos en un valor menor, las referencias locales de JNI se comportan igual que en versiones anteriores.

WebKit

  • WebKit actualizado a la versión 534.30
  • Compatibilidad con fuentes índicas (devanagari, bengalí y tamil, incluida la compatibilidad con caracteres complejos) necesario para combinar glifos) en WebView y en el navegador integrado
  • Compatibilidad con fuentes etíopes, georgianas y armenias en WebView y las navegador integrado
  • La compatibilidad con WebDriver hace te resultará más fácil probar apps que usan WebView

Navegador Android

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

Permisos

Los siguientes son permisos nuevos:

Funciones del dispositivo

Las siguientes son nuevas funciones del dispositivo:

  • FEATURE_WIFI_DIRECT: Declara que la aplicación usa Wi-Fi para las comunicaciones entre pares.

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

APIs anteriores

Además de todo lo anterior, Android 4.0 naturalmente admite todas las API de las versiones anteriores. Como la plataforma de Android 3.x solo está disponible para dispositivos con pantallas grandes, si tienes desarrollaron principalmente para teléfonos celulares, entonces es posible que no conozcas todas las APIs que se agregan a Android en estas versiones recientes.

Aquí te mostramos algunas de las APIs más notables que quizás no hayas visto y que ya están disponibles también en teléfonos celulares:

Android 3.0
  • Fragment: Es un componente de framework que te permite separar elementos de una actividad en módulos independientes que definen su propia IU y ciclo de vida. Consulta la Fragment para desarrolladores.
  • ActionBar: Es un reemplazo de la barra de título tradicional en la parte superior de la ventana de actividad. Incluye el logotipo de la aplicación en la esquina izquierda y proporciona un nuevo para los elementos del menú. Consulta la Barra de acciones.
  • Loader: Es un componente de framework que facilita los procesos de datos en combinación con los componentes de la interfaz de usuario para cargar datos dinámicamente sin bloquear la subproceso principal. Consulta la Cargadores para desarrolladores.
  • Portapapeles del sistema: Las aplicaciones pueden copiar y pegar datos (más allá del simple texto) desde y hacia el portapapeles de todo el sistema. Los datos recortados pueden ser texto sin formato, un URI o un intent. Consulta la Cómo copiar y pegar para desarrolladores.
  • Arrastrar y soltar: Es un conjunto de APIs integradas en el framework de vista que facilita la acción de arrastrar y soltar. las operaciones. Consulta la Arrastrar y soltar para desarrolladores
  • Un nuevo framework de animación flexible permite animar propiedades arbitrarias de cualquier (vista, elemento de diseño, fragmento, objeto o cualquier otro elemento) y define los aspectos de la animación, como como duración, interpolación, repetición y más. El nuevo framework permite crear animaciones en Android. más simple que nunca. Consulta la Desarrollador de animación de propiedades .
  • Gráficos y Compute Engine de RenderScript: RenderScript ofrece una representación 3D de alto rendimiento la renderización de gráficos y la API de procesamiento en el nivel nativo, que escribes en C (estándar C99) Proporciona el tipo de rendimiento que esperas de un entorno nativo sin perder la portabilidad. en varias CPU y GPU. Consulta la Desarrollador de RenderScript .
  • Gráficos 2D acelerados por hardware: Ahora puedes habilitar el renderizador OpenGL para tu aplicación estableciendo {android:hardwareAccelerated="true"} en el elemento <application> del manifiesto o para <activity> individuales o de terceros. Esto da como resultado animaciones y desplazamientos más fluidos, y un mejor rendimiento y respuesta general para el usuario interacción.

    Nota: Si estableces minSdkVersion o targetSdkVersion de la aplicación como "14" o una versión posterior, la aceleración de hardware está habilitada de forma predeterminada.

  • Y mucho, mucho más. Consulta la plataforma de Android 3.0. notas para obtener más información.
Android 3.1
  • API de USB: API nuevas y potentes para integrar los periféricos conectados con Aplicaciones para Android. Las APIs se basan en una pila USB y servicios integradas en la plataforma, lo que incluye compatibilidad con interacciones con el dispositivo y el host USB. Consulta la guía para desarrolladores sobre hosts USB y accesorio.
  • APIs de MTP/PTP: las aplicaciones pueden interactuar directamente con cámaras conectadas y otras PTP. para recibir notificaciones cuando se conectan o quitan dispositivos, administran archivos y almacenamiento en esos dispositivos y transferir archivos y metadatos desde y hacia ellos. La API de MTP implementa la interfaz de usuario subconjunto (protocolo de transferencia de imágenes) de la especificación de MTP (protocolo de transferencia multimedia). Consulta la documentación de android.mtp.
  • API de RTP: Android expone una API a su pila de protocolo de transporte en tiempo real (RTP) integrada. qué aplicaciones pueden usar para administrar la transmisión de datos interactiva o a pedido. En particular, las apps que proporcionan VoIP, presionar para hablar, conferencias y transmisión de audio pueden usar la API para iniciar y transmitir o recibir flujos de datos a través de cualquier red disponible. Consulta la documentación de android.net.rtp.
  • Compatibilidad con joysticks y otras entradas de movimiento genéricas.
  • Consulta la plataforma de Android 3.1 notas para muchas otras APIs nuevas.
Android 3.2
  • Las nuevas pantallas admiten APIs que te dan más control sobre el funcionamiento de tus aplicaciones se muestran en diferentes tamaños de pantalla. La API extiende el modelo de compatibilidad de pantalla existente con el capacidad para orientarse con precisión a rangos de tamaño de pantalla específicos por dimensiones, medidos en unidades de píxeles independientes de la densidad (como 600 dp o 720 dp de ancho), en lugar de hacerlo por tamaños de pantalla (por ejemplo, grande o extragrande). Por ejemplo, esto es importante para ayudarte distinguir entre una y una de 7" que, tradicionalmente, se agruparían como buckets “grande” pantallas. Consulta la entrada de blog, Nuevas herramientas para administrar los tamaños de pantalla.
  • Nuevas constantes para <uses-feature> para declarar requisitos de orientación de pantalla horizontal o vertical
  • El "tamaño de la pantalla" del dispositivo configuración ahora cambia durante la orientación de la pantalla cambio. Si tu app tiene como objetivo el nivel de API 13 o uno superior, debes controlar las "screenSize" cambio de configuración si también quieres controlar el cambio de configuración de "orientation". Consulta android:configChanges para obtener más información.
  • Consulta la plataforma de Android 3.2. notas para otras APIs nuevas.

Nivel de API

A la API de Android 4.0 se le asigna un número entero 14, que se almacena en el propio sistema. Este identificador, denominado "nivel de API", permite que el sistema determine correctamente si un aplicación sea compatible con el sistema antes de instalarla.

Para usar en tu aplicación las API que se introdujeron en Android 4.0, necesitas compilar el aplicación en una plataforma de Android compatible con el nivel de API 14 o mayores. Según tus necesidades, es posible que también debas agregar el atributo android:minSdkVersion="14" al <uses-sdk> .

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