API Android 4.0

Niveau d'API:14

Android 4.0 (ICE_CREAM_SANDWICH) est une version majeure de la plate-forme qui ajoute plusieurs nouvelles fonctionnalités pour les utilisateurs et les développeurs d'applications. Outre toutes les nouvelles fonctionnalités et API décrites ci-dessous, Android 4.0 est une version importante de la plate-forme, car elle permet d'utiliser l'ensemble complet d'API et de thèmes Holography d'Android 3.x sur des écrans plus petits. En tant que développeur d'applications, vous disposez désormais d'une plate-forme unique et d'un framework d'API unifié qui vous permettent de développer et de publier votre application avec un seul fichier APK. Celui-ci offre une expérience utilisateur optimisée sur les téléphones, les tablettes et plus encore, lorsque vous exécutez la même version d'Android : Android 4.0 (niveau d'API 14) ou version ultérieure.

Pour les développeurs, la plate-forme Android 4.0 est disponible en tant que composant téléchargeable pour le SDK Android. La plate-forme téléchargeable comprend une bibliothèque Android et une image système, ainsi qu'un ensemble d'apparences d'émulateur et plus encore. Pour commencer à développer ou à tester Android 4.0, utilisez Android SDK Manager afin de télécharger la plate-forme dans votre SDK.

Présentation de l'API

Les sections ci-dessous offrent une présentation technique des nouvelles API dans Android 4.0.

API de réseaux sociaux dans Contacts Provider

Les API de contact définies par le fournisseur ContactsContract ont été étendues pour prendre en charge de nouvelles fonctionnalités axées sur les réseaux sociaux, telles qu'un profil personnel pour le propriétaire de l'appareil et la possibilité pour les utilisateurs d'inviter des contacts individuels sur les réseaux sociaux installés sur l'appareil.

Profil utilisateur

Android inclut désormais un profil personnel qui représente le propriétaire de l'appareil, comme défini dans la table ContactsContract.Profile. Les applications de réseau social qui conservent l'identité d'un utilisateur peuvent contribuer aux données de profil de l'utilisateur en créant une entrée ContactsContract.RawContacts dans le ContactsContract.Profile. En d'autres termes, les contacts bruts représentant l'utilisateur de l'appareil n'appartiennent pas à la table de contacts bruts traditionnelle définie par l'URI ContactsContract.RawContacts. À la place, vous devez ajouter un contact brut de profil dans la table à l'adresse CONTENT_RAW_CONTACTS_URI. Les contacts bruts de cette table sont ensuite regroupés dans un seul profil visible par l'utilisateur intitulé "Moi".

L'ajout d'un nouveau contact brut pour le profil nécessite l'autorisation android.Manifest.permission#WRITE_PROFILE. De même, pour lire la table de profil, vous devez demander l'autorisation android.Manifest.permission#READ_PROFILE. Toutefois, la plupart des applications ne devraient pas avoir besoin de lire le profil utilisateur, même lorsqu'elles contribuent à des données dans le profil. La lecture du profil utilisateur est une autorisation sensible. Attendez-vous à ce que les utilisateurs soient sceptiques à l'égard des applications qui la demandent.

Intent d'invitation

L'action d'intent INVITE_CONTACT permet à une application d'appeler une action indiquant que l'utilisateur souhaite ajouter un contact à un réseau social. L'application qui reçoit l'application l'utilise pour inviter le contact spécifié à rejoindre ce réseau social. La plupart des applications seront traitées en réception de cette opération. Par exemple, l'application Contacts intégrée appelle l'intent d'invitation lorsque l'utilisateur sélectionne "Ajouter une connexion" pour une application de réseau social spécifique figurant dans ses coordonnées.

Pour que votre application soit visible dans la liste "Ajouter une connexion", elle doit fournir un adaptateur de synchronisation permettant de synchroniser les coordonnées à partir de votre réseau social. Vous devez ensuite indiquer au système que votre application répond à l'intent INVITE_CONTACT en ajoutant l'attribut inviteContactActivity au fichier de configuration de synchronisation de votre application, avec le nom complet de l'activité que le système doit démarrer lors de l'envoi de l'intent d'invitation. L'activité qui démarre peut ensuite récupérer l'URI du contact en question à partir des données de l'intent et effectuer le travail nécessaire pour inviter ce contact sur le réseau ou ajouter la personne aux connexions de l'utilisateur.

Photos volumineuses

Android est désormais compatible avec les photos haute résolution des contacts. Désormais, lorsque vous transférez une photo vers une fiche de contact, le système la traite à la fois sous la forme d'une vignette de 96 x 96 pixels (comme c'était le cas auparavant) et d'une "photo display" 256 x 256 stockée dans un nouveau magasin de photos basé sur des fichiers (les dimensions exactes choisies par le système peuvent varier à l'avenir). Vous pouvez ajouter une grande photo à un contact en plaçant une grande photo dans la colonne PHOTO habituelle d'une ligne de données, que le système traitera ensuite dans la vignette appropriée et affichera les enregistrements de photos.

Commentaires sur l'utilisation des contacts

Les nouvelles API ContactsContract.DataUsageFeedback vous permettent de suivre la fréquence à laquelle l'utilisateur utilise des méthodes particulières pour contacter les utilisateurs, telles que la fréquence à laquelle il utilise chaque numéro de téléphone ou adresse e-mail. Ces informations permettent d'améliorer le classement de chaque méthode de contact associée à chaque personne et de fournir de meilleures suggestions pour contacter chaque personne.

Fournisseur d'agenda

Les nouvelles API Calendar vous permettent de consulter, d'ajouter, de modifier et de supprimer des agendas, des événements, des participants, des rappels et des alertes, qui sont stockés dans le fournisseur d'agendas.

Diverses applications et widgets peuvent utiliser ces API pour lire et modifier des événements d'agenda. Toutefois, certains des cas d'utilisation les plus séduisants sont les adaptateurs de synchronisation qui synchronisent l'agenda de l'utilisateur à partir d'autres services d'agenda avec le fournisseur d'agenda, afin de proposer un emplacement unifié pour tous les événements de l'utilisateur. Les événements Google Agenda, par exemple, sont synchronisés avec le fournisseur d'agenda par l'adaptateur de synchronisation Google Agenda, ce qui permet de les afficher avec l'application Agenda intégrée à Android.

Le modèle de données des agendas et des informations liées aux événements dans le fournisseur d'agendas est défini par CalendarContract. Toutes les données d'agenda de l'utilisateur sont stockées dans plusieurs tables définies par différentes sous-classes de CalendarContract:

  • La table CalendarContract.Calendars contient les informations spécifiques à l'agenda. Chaque ligne de cette table contient les détails d'un seul agenda, tels que le nom, la couleur, les informations de synchronisation, etc.
  • La table CalendarContract.Events contient des informations spécifiques aux événements. Chaque ligne de cette table contient les informations sur un seul événement, telles que le titre, le lieu, l'heure de début, l'heure de fin, etc. L'événement peut se produire une fois ou se répéter plusieurs fois. Les participants, les rappels et les propriétés étendues sont stockés dans des tables distinctes et utilisent le _ID de l'événement pour les associer à celui-ci.
  • La table CalendarContract.Instances contient les heures de début et de fin des occurrences d'un événement. Chaque ligne de cette table représente une seule occurrence. Pour les événements ponctuels, il existe un mappage "un à un" des instances et des événements. Pour les événements récurrents, plusieurs lignes sont générées automatiquement pour correspondre aux occurrences multiples de cet événement.
  • La table CalendarContract.Attendees contient les informations sur les participants à l'événement ou les invités. Chaque ligne représente un seul invité d'un événement. Il spécifie le type d'invité de la personne et sa réponse à l'événement.
  • La table CalendarContract.Reminders contient les données d'alerte/notification. Chaque ligne représente une alerte spécifique pour un événement. Un événement peut avoir plusieurs rappels. Le nombre de rappels par événement est spécifié dans MAX_REMINDERS, qui est défini par l'adaptateur de synchronisation propriétaire de l'agenda donné. Les rappels sont spécifiés en nombre de minutes avant la programmation de l'événement et spécifient une méthode d'alarme (par exemple, une alerte, un e-mail ou un SMS pour le rappeler à l'utilisateur).
  • La table CalendarContract.ExtendedProperties contient les champs de données opaques utilisés par l'adaptateur de synchronisation. Le fournisseur n'effectue aucune action sur les éléments de cette table, sauf pour les supprimer lorsque leurs événements associés sont supprimés.

Pour accéder aux données d'agenda d'un utilisateur avec le fournisseur d'agendas, votre application doit demander l'autorisation READ_CALENDAR (pour l'accès en lecture) et WRITE_CALENDAR (pour l'accès en écriture).

Intention d'événement

Si vous souhaitez simplement ajouter un événement à l'agenda de l'utilisateur, vous pouvez utiliser un intent ACTION_INSERT avec les données définies par Events.CONTENT_URI afin de démarrer dans l'application Agenda une activité qui crée des événements. L'utilisation de l'intent ne nécessite aucune autorisation. Vous pouvez spécifier les détails de l'événement avec les extras suivants:

Fournisseur de messagerie vocale

Le nouveau fournisseur de messagerie vocale permet aux applications d'ajouter des messages vocaux à l'appareil afin de présenter tous les messages vocaux de l'utilisateur dans une seule présentation visuelle. Par exemple, il est possible qu'un utilisateur dispose de plusieurs sources de messagerie vocale : l'une provient du fournisseur de services du téléphone, et d'autres de la VoIP ou d'autres services vocaux alternatifs. Ces applications peuvent utiliser les API Message Provider pour ajouter leurs messages vocaux à l'appareil. L'application Téléphone intégrée présente ensuite tous les messages vocaux à l'utilisateur dans une présentation unifiée. Bien que l'application Téléphone du système soit la seule application capable de lire tous les messages vocaux, chaque application qui fournit des messages vocaux peut lire ceux qu'elle a ajoutés au système (mais ne peut pas lire les messages vocaux d'autres services).

Étant donné que les API n'autorisent actuellement pas les applications tierces à lire tous les messages vocaux du système, les seules applications tierces qui doivent utiliser les API de messagerie vocale sont celles qui ont un message vocal à distribuer à l'utilisateur.

La classe VoicemailContract définit le fournisseur de contenu du fournisseur de message vocal. Les sous-classes VoicemailContract.Voicemails et VoicemailContract.Status fournissent des tables dans lesquelles les applications peuvent insérer des données de messagerie vocale pour les stocker sur l'appareil. Pour obtenir un exemple d'application de fournisseur de messagerie vocale, consultez la démonstration du fournisseur de messagerie vocale.

Multimédia

Android 4.0 ajoute plusieurs nouvelles API pour les applications qui interagissent avec des contenus multimédias tels que des photos, des vidéos et de la musique.

Effets multimédias

Un nouveau framework d'effets multimédias vous permet d'appliquer divers effets visuels à des images et à des vidéos. Par exemple, les effets d'image vous permettent de corriger facilement les yeux rouges, de convertir une image en nuances de gris, d'ajuster la luminosité, d'ajuster la saturation, de faire pivoter une image, d'appliquer un effet fisheye, etc. Le système effectue tous les traitements des effets sur le GPU pour obtenir des performances optimales.

Pour des performances optimales, les effets sont appliqués directement aux textures OpenGL. Votre application doit donc disposer d'un contexte OpenGL valide avant de pouvoir utiliser les API d'effets. Les textures auxquelles vous appliquez des effets peuvent provenir de bitmaps, de vidéos ou même de l'appareil photo. Toutefois, les textures doivent respecter certaines restrictions:

  1. Elles doivent être liées à une image de texture GL_TEXTURE_2D.
  2. Elles doivent contenir au moins un niveau de mipmaps

Un objet Effect définit un seul effet multimédia que vous pouvez appliquer à un cadre d'image. Le workflow de base pour créer une Effect est le suivant:

  1. Appelez EffectContext.createWithCurrentGlContext() à partir de votre contexte OpenGL ES 2.0.
  2. Utilisez le EffectContext renvoyé pour appeler EffectContext.getFactory(), qui renvoie une instance de EffectFactory.
  3. Appelez createEffect() en lui transmettant un nom d'effet à partir de @link android.media.effect.EffectFactory}, tel que EFFECT_FISHEYE ou EFFECT_VIGNETTE.

Vous pouvez ajuster les paramètres d'un effet en appelant setParameter() et en transmettant un nom et une valeur de paramètre. Chaque type d'effet accepte différents paramètres, qui sont documentés avec le nom de l'effet. Par exemple, EFFECT_FISHEYE comporte un paramètre pour le scale de la distorsion.

Pour appliquer un effet à une texture, appelez apply() sur Effect et transmettez la texture d'entrée, sa largeur et sa hauteur, ainsi que la texture de sortie. La texture d'entrée doit être liée à une image de texture GL_TEXTURE_2D (généralement en appelant la fonction glTexImage2D()). Vous pouvez fournir plusieurs niveaux de mipmaps. Si la texture de sortie n'a pas été liée à une image de texture, elle sera automatiquement liée par l'effet en tant que GL_TEXTURE_2D et avec un niveau de mipmap (0), qui aura la même taille que l'entrée.

La compatibilité de tous les effets listés dans EffectFactory est garantie. Toutefois, certains effets supplémentaires disponibles à partir de bibliothèques externes ne sont pas compatibles avec tous les appareils. Vous devez donc d'abord vérifier si l'effet souhaité à partir de la bibliothèque externe est pris en charge en appelant isEffectSupported().

Client de la télécommande

Le nouveau RemoteControlClient permet aux lecteurs multimédias d'activer les commandes de lecture à partir de clients de télécommande, tels que l'écran de verrouillage de l'appareil. Les lecteurs multimédias peuvent également afficher sur la télécommande des informations sur le contenu multimédia en cours de lecture, telles que des informations sur les titres et des pochettes d'album.

Pour activer les clients de télécommande pour votre lecteur multimédia, instanciez un RemoteControlClient avec son constructeur, en lui transmettant un PendingIntent qui diffuse ACTION_MEDIA_BUTTON. L'intent doit également déclarer le composant BroadcastReceiver explicite dans votre application qui gère l'événement ACTION_MEDIA_BUTTON.

Pour déclarer les entrées de commandes multimédias que votre lecteur peut gérer, vous devez appeler setTransportControlFlags() sur votre RemoteControlClient, en transmettant un ensemble d'indicateurs FLAG_KEY_MEDIA_*, tels que FLAG_KEY_MEDIA_PREVIOUS et FLAG_KEY_MEDIA_NEXT.

Vous devez ensuite enregistrer votre RemoteControlClient en le transmettant à MediaManager.registerRemoteControlClient(). Une fois enregistré, le broadcast receiver que vous avez déclaré lors de l'instanciation de RemoteControlClient reçoit des événements ACTION_MEDIA_BUTTON lorsqu'un utilisateur appuie sur un bouton d'une télécommande. L'intent que vous recevez inclut le KeyEvent pour la touche multimédia appuyée, que vous pouvez récupérer à partir de l'intent avec getParcelableExtra(Intent.EXTRA_KEY_EVENT).

Pour afficher sur la télécommande des informations sur le contenu multimédia en cours de lecture, appelez editMetaData() et ajoutez des métadonnées au RemoteControlClient.MetadataEditor renvoyé. Vous pouvez fournir un bitmap pour les illustrations d'éléments multimédias, des informations numériques telles que le temps écoulé et des informations textuelles telles que le titre de la piste. Pour en savoir plus sur les clés disponibles, consultez les options METADATA_KEY_* dans MediaMetadataRetriever.

Pour voir un exemple d'implémentation, consultez Random Music Player, qui fournit une logique de compatibilité permettant d'activer le client de télécommande sur les appareils Android 4.0 tout en continuant à prendre en charge les appareils à partir d'Android 2.1.

Lecteur multimédia

  • La diffusion de contenus multimédias en ligne à partir de MediaPlayer nécessite désormais l'autorisation INTERNET. Si vous utilisez MediaPlayer pour lire du contenu à partir d'Internet, veillez à ajouter l'autorisation INTERNET à votre fichier manifeste. Sinon, la lecture de contenus multimédias ne fonctionnera pas à partir d'Android 4.0.
  • setSurface() vous permet de définir une Surface qui se comporte comme le récepteur vidéo.
  • setDataSource() vous permet d'envoyer des en-têtes HTTP supplémentaires avec votre requête, ce qui peut être utile pour le streaming HTTP(S) en direct
  • Le streaming en direct HTTP(S) respecte désormais les cookies HTTP dans toutes les requêtes

Types de supports

Android 4.0 est compatible avec les fonctionnalités suivantes:

  • Protocole de streaming en direct HTTP/HTTPS version 3
  • Encodage audio AAC brut ADTS
  • Images WEBP
  • Vidéo Matroska

Pour en savoir plus, consultez la page Formats multimédias compatibles.

Appareil photo

La classe Camera inclut désormais des API permettant de détecter les visages et de contrôler les zones de mise au point et de mesure.

Détection de visages

Les applications d'appareil photo peuvent désormais améliorer leurs capacités grâce aux API de détection de visages d'Android. Elles détectent non seulement le visage d'un sujet, mais aussi des caractéristiques spécifiques du visage, comme les yeux et la bouche.

Pour détecter les visages dans l'application Appareil photo, vous devez enregistrer un Camera.FaceDetectionListener en appelant setFaceDetectionListener(). Vous pouvez ensuite démarrer la surface de votre caméra et commencer à détecter des visages en appelant startFaceDetection().

Lorsque le système détecte un ou plusieurs visages dans la scène de la caméra, il appelle le rappel onFaceDetection() dans votre implémentation de Camera.FaceDetectionListener, y compris un tableau d'objets Camera.Face.

Une instance de la classe Camera.Face fournit diverses informations sur le visage détecté, y compris:

  • Rect qui spécifie les limites du visage par rapport au champ de vision actuel de la caméra.
  • Nombre entier compris entre 1 et 100 qui indique le degré de confiance du système quant à l'existence d'un visage humain.
  • Un identifiant unique vous permettant de suivre plusieurs visages
  • Plusieurs objets Point qui indiquent l'emplacement des yeux et de la bouche.

Remarque:Il est possible que la détection de visages ne soit pas compatible avec certains appareils. Vous devez donc vérifier en appelant getMaxNumDetectedFaces() et vous assurer que la valeur renvoyée est supérieure à zéro. En outre, certains appareils peuvent ne pas être compatibles avec l'identification des yeux et de la bouche. Dans ce cas, les champs de l'objet Camera.Face seront nuls.

Domaines d'intervention et de mesure

Les applications d'appareil photo peuvent désormais contrôler les zones utilisées par l'appareil photo pour la mise au point, ainsi que pour mesurer la balance des blancs et l'exposition automatique. Ces deux fonctionnalités utilisent la nouvelle classe Camera.Area pour spécifier la zone de la vue actuelle de la caméra qui doit être mise au point ou mesurée. Une instance de la classe Camera.Area définit les limites de la zone avec un Rect et la pondération de la zone (représentant son niveau d'importance par rapport aux autres zones concernées) avec un nombre entier.

Avant de définir une zone de mise au point ou de mesure, vous devez d'abord appeler getMaxNumFocusAreas() ou getMaxNumMeteringAreas(), respectivement. S'ils renvoient zéro, l'appareil n'est pas compatible avec la fonctionnalité correspondante.

Pour spécifier les zones de mise au point ou de mesure à utiliser, il vous suffit d'appeler setFocusAreas() ou setMeteringAreas(). Chacun d'entre eux prend une List d'objets Camera.Area qui indiquent les zones à prendre en compte pour la mise au point ou la mesure. Par exemple, vous pouvez implémenter une fonctionnalité qui permet à l'utilisateur de définir la zone de mise au point en appuyant sur une zone de l'aperçu, que vous convertissez ensuite en objet Camera.Area et que l'appareil photo doit effectuer la mise au point sur cette zone de la scène. La mise au point ou l'exposition dans cette zone sont actualisées en continu à mesure que la scène change.

Mise au point automatique continue pour les photos

Vous pouvez désormais activer la mise au point automatique continue (CAF) lorsque vous prenez des photos. Pour activer CAF dans votre application d'appareil photo, transmettez FOCUS_MODE_CONTINUOUS_PICTURE à setFocusMode(). Lorsque vous êtes prêt à prendre une photo, appelez autoFocus(). Votre Camera.AutoFocusCallback reçoit immédiatement un rappel pour indiquer si la mise au point a été effectuée. Pour réactiver CAF après avoir reçu le rappel, vous devez appeler cancelAutoFocus().

Remarque:La mise au point automatique continue est également prise en charge lors de la capture vidéo à l'aide de FOCUS_MODE_CONTINUOUS_VIDEO, qui a été ajouté au niveau d'API 9.

Autres fonctionnalités de la caméra

  • Lorsque vous enregistrez une vidéo, vous pouvez désormais appeler takePicture() pour sauvegarder une photo sans interrompre la session vidéo. Avant cela, appelez isVideoSnapshotSupported() pour vous assurer que le matériel est compatible.
  • Vous pouvez désormais verrouiller l'exposition automatique et la balance des blancs à l'aide de setAutoExposureLock() et setAutoWhiteBalanceLock() pour empêcher la modification de ces propriétés.
  • Vous pouvez désormais appeler setDisplayOrientation() pendant que l'aperçu de l'appareil photo est en cours d'exécution. Auparavant, vous ne pouviez appeler cette méthode qu'avant de lancer l'aperçu, mais vous pouvez désormais modifier l'orientation à tout moment.

Intents de diffusion de la caméra

  • Camera.ACTION_NEW_PICTURE : indique que l'utilisateur a pris une nouvelle photo. L'application Appareil photo intégrée appelle cette diffusion après la prise d'une photo. Les applications d'appareil photo tierces doivent également diffuser cet intent après la prise de vue.
  • Camera.ACTION_NEW_VIDEO : indique que l'utilisateur a enregistré une nouvelle vidéo. L'application Appareil photo intégrée appelle cette diffusion après l'enregistrement d'une vidéo. Les applications d'appareil photo tierces doivent également diffuser cet intent après avoir enregistré une vidéo.

Android Beam (push NDEF avec NFC)

Android Beam est une nouvelle fonctionnalité NFC qui vous permet d'envoyer des messages NDEF d'un appareil à un autre (processus également appelé "envoi NDEF"). Le transfert de données est lancé lorsque deux appareils Android compatibles avec Android Beam se trouvent à proximité (environ 4 cm), généralement le dos de l'appareil. Les données à l'intérieur du message NDEF peuvent contenir toutes les données que vous souhaitez partager entre les appareils. Par exemple, l'application Contacts partage des contacts, YouTube partage des vidéos et le navigateur partage des URL à l'aide d'Android Beam.

Pour transmettre des données entre des appareils à l'aide d'Android Beam, vous devez créer un NdefMessage contenant les informations que vous souhaitez partager lorsque votre activité est exécutée au premier plan. Vous devez ensuite transmettre NdefMessage au système de l'une des deux manières suivantes:

  • Définissez un seul élément NdefMessage à envoyer pendant l'activité:

    Appelez setNdefPushMessage() à tout moment pour définir le message que vous souhaitez envoyer. Par exemple, vous pouvez appeler cette méthode et lui transmettre votre NdefMessage lors de la méthode onCreate() de votre activité. Ensuite, chaque fois qu'Android Beam est activé sur un autre appareil alors que l'activité est au premier plan, le système envoie NdefMessage à l'autre appareil.

  • Définissez le NdefMessage à transférer au moment du lancement d'Android Beam:

    Implémentez NfcAdapter.CreateNdefMessageCallback, dans lequel votre implémentation de la méthode createNdefMessage() renvoie le NdefMessage que vous souhaitez envoyer. Transmettez ensuite l'implémentation de NfcAdapter.CreateNdefMessageCallback à setNdefPushMessageCallback().

    Dans ce cas, lorsque Android Beam est activé avec un autre appareil alors que votre activité est au premier plan, le système appelle createNdefMessage() pour récupérer le NdefMessage que vous souhaitez envoyer. Cela vous permet de définir NdefMessage pour qu'il ne soit transmis qu'une fois qu'Android Beam est lancé, au cas où le contenu du message pourrait varier tout au long de la vie de l'activité.

Si vous souhaitez exécuter un code spécifique une fois que le système a réussi à transmettre votre message NDEF à l'autre appareil, vous pouvez implémenter NfcAdapter.OnNdefPushCompleteCallback et le définir avec setNdefPushCompleteCallback(). Le système appellera ensuite onNdefPushComplete() une fois le message distribué.

Sur l'appareil récepteur, le système distribue les messages push NDEF de la même manière que les tags NFC standards. Le système appelle un intent avec l'action ACTION_NDEF_DISCOVERED pour démarrer une activité, avec une URL ou un type MIME défini en fonction du premier NdefRecord du NdefMessage. Pour l'activité à laquelle vous souhaitez répondre, vous pouvez déclarer des filtres d'intent pour les URL ou les types MIME importants pour votre application. Pour en savoir plus sur Tag Dispatch, consultez le guide du développeur sur le NFC.

Si vous souhaitez que votre NdefMessage contienne un URI, vous pouvez maintenant utiliser la méthode pratique createUri pour construire une nouvelle NdefRecord basée sur une chaîne ou un objet Uri. Si l'URI est un format spécial que votre application doit également recevoir lors d'un événement Android Beam, vous devez créer un filtre d'intent pour votre activité à l'aide du même schéma d'URI afin de recevoir le message NDEF entrant.

Vous devez également transmettre un "enregistrement d'application Android" avec votre NdefMessage afin de garantir que votre application gère le message NDEF entrant, même si d'autres applications filtrent la même action d'intent. Vous pouvez créer un enregistrement d'application Android en appelant createApplicationRecord() et en lui transmettant le nom de package de votre application. Lorsque l'autre appareil reçoit le message NDEF avec l'enregistrement d'application et que plusieurs applications contiennent des activités qui gèrent l'intent spécifié, le système envoie toujours le message à l'activité de votre application (en fonction de l'enregistrement d'application correspondant). Si votre application n'est pas installée sur l'appareil cible, le système utilise l'enregistrement d'application Android pour lancer Google Play et rediriger l'utilisateur vers l'application afin de l'installer.

Si votre application n'utilise pas d'API NFC pour envoyer des messages push NDEF, Android fournit un comportement par défaut: lorsque votre application est exécutée au premier plan sur un appareil et qu'Android Beam est appelé avec un autre appareil Android, l'autre appareil reçoit un message NDEF avec un enregistrement d'application Android qui identifie votre application. Si l'application est installée sur l'appareil récepteur, le système la lance. Si ce n'est pas le cas, Google Play s'ouvre et redirige l'utilisateur vers votre application pour l'installer.

Pour en savoir plus sur Android Beam et d'autres fonctionnalités NFC, consultez le guide du développeur sur les principes de base de la technologie NFC. Pour obtenir un exemple de code avec Android Beam, consultez la démonstration Android Beam.

Wi-Fi P2P

Android est désormais compatible avec les connexions Wi-Fi peer-to-peer (P2P) entre des appareils Android et d'autres types d'appareils (conformément au programme de certification Wi-Fi DirectTM de la Wi-Fi Alliance) sans point d'accès ni connexion Internet. Le framework Android fournit un ensemble d'API Wi-Fi P2P qui vous permettent de détecter d'autres appareils et de vous y connecter lorsque chacun d'eux est compatible avec le Wi-Fi P2P, puis de communiquer sur une connexion rapide sur des distances beaucoup plus longues qu'une connexion Bluetooth.

Un nouveau package, android.net.wifi.p2p, contient toutes les API permettant d'effectuer des connexions peer-to-peer via le Wi-Fi. La classe principale avec laquelle vous devez travailler est WifiP2pManager, que vous pouvez vous procurer en appelant getSystemService(WIFI_P2P_SERVICE). WifiP2pManager inclut des API qui vous permettent de:

  • Initialisez votre application pour les connexions P2P en appelant initialize()
  • Découvrez les appareils à proximité en appelant discoverPeers()
  • Démarrez une connexion P2P en appelant connect()
  • Et plus encore

D'autres interfaces et classes sont également nécessaires, par exemple:

  • L'interface WifiP2pManager.ActionListener vous permet de recevoir des rappels lorsqu'une opération, telle que la découverte de pairs ou la connexion à ceux-ci, réussit ou échoue.
  • L'interface WifiP2pManager.PeerListListener vous permet de recevoir des informations sur les pairs découverts. Le rappel fournit un WifiP2pDeviceList, à partir duquel vous pouvez récupérer un objet WifiP2pDevice pour chaque appareil à portée et obtenir des informations telles que le nom et l'adresse de l'appareil, le type d'appareil, les configurations WPS compatibles, etc.
  • L'interface WifiP2pManager.GroupInfoListener vous permet de recevoir des informations sur un groupe P2P. Le rappel fournit un objet WifiP2pGroup, qui fournit des informations de groupe telles que le propriétaire, le nom du réseau et la phrase secrète.
  • WifiP2pManager.ConnectionInfoListener vous permet de recevoir des informations sur la connexion actuelle. Le rappel fournit un objet WifiP2pInfo, qui contient des informations telles que la création d'un groupe et son propriétaire.

Pour utiliser les API Wi-Fi P2P, votre application doit demander les autorisations utilisateur suivantes:

  • ACCESS_WIFI_STATE
  • CHANGE_WIFI_STATE
  • INTERNET (même si techniquement votre application ne se connecte pas à Internet, la communication avec des pairs P2P Wi-Fi avec des sockets Java standards nécessite une autorisation Internet.)

Le système Android diffuse également plusieurs actions différentes lors de certains événements Wi-Fi P2P:

Pour en savoir plus, consultez la documentation WifiP2pManager. Consultez également l'exemple d'application de démonstration Wi-Fi P2P.

Appareils Bluetooth Health

Android est désormais compatible avec les appareils de profil de santé Bluetooth. Vous pouvez donc créer des applications qui utilisent le Bluetooth pour communiquer avec les appareils de santé compatibles avec le Bluetooth, tels que les cardiofréquencemètres, les compteurs de sang, les thermomètres et les balances.

Comme pour les casques standards et les appareils à profil A2DP, vous devez appeler getProfileProxy() avec un BluetoothProfile.ServiceListener et le type de profil HEALTH pour établir une connexion avec l'objet proxy de profil.

Une fois que vous avez acquis le proxy du profil de santé (l'objet BluetoothHealth), la connexion aux appareils de santé associés et la communication avec eux impliquent les nouvelles classes Bluetooth suivantes:

  • BluetoothHealthCallback: vous devez étendre cette classe et implémenter les méthodes de rappel pour recevoir des informations sur les modifications de l'état d'enregistrement de l'application et de l'état du canal Bluetooth.
  • BluetoothHealthAppConfiguration: lors des rappels à votre BluetoothHealthCallback, vous recevrez une instance de cet objet, qui fournit des informations de configuration sur l'appareil de santé Bluetooth disponible, que vous devez utiliser pour effectuer diverses opérations, telles que le lancement et l'arrêt de connexions avec les API BluetoothHealth.

Pour en savoir plus sur l'utilisation du profil de santé Bluetooth, consultez la documentation de BluetoothHealth.

Accessibilité

Android 4.0 améliore l'accessibilité pour les utilisateurs malvoyants grâce au nouveau mode Explorer au toucher et aux API étendues qui vous permettent de fournir plus d'informations sur le contenu affiché ou de développer des services d'accessibilité avancés.

Mode Explorer au toucher

Les utilisateurs souffrant d'une perte de vision peuvent désormais explorer l'écran en appuyant sur l'écran et en le faisant glisser pour entendre les descriptions vocales du contenu. Comme le mode Explorer au toucher fonctionne comme un curseur virtuel, il permet aux lecteurs d'écran d'identifier le texte descriptif de la même manière que les lecteurs d'écran le font lorsque l'utilisateur navigue avec un pavé directionnel ou un trackball, en lisant les informations fournies par android:contentDescription et setContentDescription() lors d'un événement de survol simulé. N'oubliez donc pas que vous devez fournir un texte descriptif pour les affichages de votre application, en particulier pour ImageButton, EditText, ImageView et les autres widgets qui ne contiennent pas nécessairement de texte descriptif.

Accessibilité pour les vues

Pour améliorer les informations disponibles pour les services d'accessibilité tels que les lecteurs d'écran, vous pouvez implémenter de nouvelles méthodes de rappel pour les événements d'accessibilité dans vos composants View personnalisés.

Il est important de noter d'abord que le comportement de la méthode sendAccessibilityEvent() a changé dans Android 4.0. Comme dans la version précédente d'Android, lorsque l'utilisateur active les services d'accessibilité sur l'appareil et qu'un événement d'entrée tel qu'un clic ou un pointage se produit, la vue correspondante est avertie via un appel à sendAccessibilityEvent(). Auparavant, l'implémentation de sendAccessibilityEvent() initialisait un AccessibilityEvent et l'envoyait à AccessibilityManager. Le nouveau comportement implique des méthodes de rappel supplémentaires qui permettent à la vue et à ses parents d'ajouter des informations contextuelles à l'événement:

  1. Lorsqu'elles sont appelées, les méthodes sendAccessibilityEvent() et sendAccessibilityEventUnchecked() s'appliquent à onInitializeAccessibilityEvent().

    Les implémentations personnalisées de View peuvent souhaiter implémenter onInitializeAccessibilityEvent() pour joindre des informations d'accessibilité supplémentaires au AccessibilityEvent, mais elles doivent également appeler la super-implémentation pour fournir des informations par défaut telles que la description de contenu standard, l'index de l'élément, etc. Toutefois, vous ne devez pas ajouter de texte supplémentaire à ce rappel, car cela se produit par la suite.

  2. Une fois initialisé, si l'événement est de plusieurs types et doit être renseigné avec des informations textuelles, la vue reçoit un appel à dispatchPopulateAccessibilityEvent(), qui retarde le rappel onPopulateAccessibilityEvent().

    Les implémentations personnalisées de View doivent généralement implémenter onPopulateAccessibilityEvent() pour ajouter du contenu textuel supplémentaire à AccessibilityEvent si le texte android:contentDescription est manquant ou insuffisant. Pour ajouter une description textuelle à AccessibilityEvent, appelez getText().add().

  3. À ce stade, View fait remonter l'événement dans la hiérarchie des vues en appelant requestSendAccessibilityEvent() sur la vue parente. Chaque vue parent a ensuite la possibilité d'améliorer les informations d'accessibilité en ajoutant un AccessibilityRecord, jusqu'à ce qu'elle atteigne la vue racine, ce qui envoie l'événement à AccessibilityManager avec sendAccessibilityEvent().

En plus des nouvelles méthodes ci-dessus, qui sont utiles lors de l'extension de la classe View, vous pouvez également intercepter ces rappels d'événements sur n'importe quel View en étendant AccessibilityDelegate et en le définissant sur la vue avec setAccessibilityDelegate(). Dans ce cas, chaque méthode d'accessibilité de la vue reporte l'appel à la méthode correspondante dans le délégué. Par exemple, lorsque la vue reçoit un appel à onPopulateAccessibilityEvent(), elle le transmet à la même méthode dans View.AccessibilityDelegate. Toutes les méthodes non gérées par le délégué sont renvoyées directement à l'affichage pour le comportement par défaut. Cela vous permet de ne remplacer que les méthodes nécessaires pour une vue donnée, sans étendre la classe View.

Si vous souhaitez maintenir la compatibilité avec les versions d'Android antérieures à la version 4.0, tout en prenant en charge les nouvelles API d'accessibilité, utilisez la dernière version de la bibliothèque Support v4 (dans Compatibility Package, r4) à l'aide d'un ensemble de classes utilitaires qui fournissent les nouvelles API d'accessibilité dans une conception rétrocompatible.

Services d'accessibilité

Si vous développez un service d'accessibilité, les informations sur les différents événements d'accessibilité ont été considérablement étendues pour permettre aux utilisateurs de bénéficier d'informations d'accessibilité plus avancées. En particulier, les événements sont générés en fonction de la composition des vues, ce qui fournit de meilleures informations contextuelles et permet aux services d'accessibilité de traverser les hiérarchies de vues pour obtenir des informations supplémentaires sur les vues et gérer des cas particuliers.

Si vous développez un service d'accessibilité (tel qu'un lecteur d'écran), vous pouvez accéder à des informations de contenu supplémentaires et traverser des hiérarchies de vues en procédant comme suit:

  1. Lorsque vous recevez un AccessibilityEvent d'une application, appelez AccessibilityEvent.getRecord() pour récupérer un AccessibilityRecord spécifique (plusieurs enregistrements peuvent être associés à l'événement).
  2. À partir de AccessibilityEvent ou d'un AccessibilityRecord individuel, vous pouvez appeler getSource() pour récupérer un objet AccessibilityNodeInfo.

    Un AccessibilityNodeInfo représente un nœud unique du contenu de la fenêtre dans un format qui vous permet d'interroger les informations d'accessibilité de ce nœud. L'objet AccessibilityNodeInfo renvoyé par AccessibilityEvent décrit la source de l'événement, tandis que la source d'un AccessibilityRecord décrit le prédécesseur de la source de l'événement.

  3. Avec AccessibilityNodeInfo, vous pouvez interroger des informations à son sujet, appeler getParent() ou getChild() pour parcourir la hiérarchie des vues, et même ajouter des vues enfants au nœud.

Pour que votre application se publie sur le système en tant que service d'accessibilité, elle doit déclarer un fichier de configuration XML correspondant à AccessibilityServiceInfo. Pour en savoir plus sur la création d'un service d'accessibilité, consultez AccessibilityService et SERVICE_META_DATA afin d'en savoir plus sur la configuration XML.

Autres API d'accessibilité

Si vous vous intéressez à l'état d'accessibilité de l'appareil, AccessibilityManager propose de nouvelles API, telles que:

Services de correction orthographique

Un nouveau framework de correcteur orthographique permet aux applications de créer des vérificateurs orthographiques d'une manière semblable au framework du mode de saisie (pour les IME). Pour créer un correcteur orthographique, vous devez implémenter un service qui étend SpellCheckerService et étende la classe SpellCheckerService.Session pour fournir des suggestions orthographiques basées sur le texte fourni par les méthodes de rappel de l'interface. Dans les méthodes de rappel SpellCheckerService.Session, vous devez renvoyer les suggestions d'orthographe en tant qu'objets SuggestionsInfo.

Les applications utilisant un service de correcteur orthographique doivent déclarer l'autorisation BIND_TEXT_SERVICE conformément aux exigences du service. Le service doit également déclarer un filtre d'intent avec l'action <action android:name="android.service.textservice.SpellCheckerService" /> et inclure un élément <meta-data> qui déclare les informations de configuration pour le correcteur orthographique.

Consultez les exemples d'applications Service de correcteur orthographique et client de correcteur orthographique pour obtenir des exemples de code.

Moteurs de synthèse vocale

Les API de synthèse vocale d'Android ont été considérablement étendues pour permettre aux applications d'implémenter plus facilement des moteurs de synthèse vocale personnalisés, tandis que les applications qui souhaitent utiliser un moteur de synthèse vocale disposent de quelques nouvelles API pour sélectionner un moteur.

Utiliser des moteurs de synthèse vocale

Dans les versions précédentes d'Android, vous pouviez utiliser la classe TextToSpeech pour effectuer des opérations de synthèse vocale à l'aide du moteur de synthèse vocale fourni par le système, ou définir un moteur personnalisé à l'aide de setEngineByPackageName(). Dans Android 4.0, la méthode setEngineByPackageName() est obsolète. Vous pouvez désormais spécifier le moteur à utiliser avec un nouveau constructeur TextToSpeech qui accepte le nom de package d'un moteur de synthèse vocale.

Vous pouvez également interroger les moteurs de synthèse vocale disponibles à l'aide de getEngines(). Cette méthode renvoie une liste d'objets TextToSpeech.EngineInfo, qui incluent des métadonnées, telles que l'icône, le libellé et le nom du package du moteur.

Développer des moteurs de synthèse vocale

Auparavant, les moteurs personnalisés exigeaient qu'ils soient créés à l'aide d'un fichier d'en-tête natif non documenté. Android 4.0 propose un ensemble complet d'API de framework permettant de créer des moteurs de synthèse vocale.

La configuration de base nécessite une implémentation de TextToSpeechService qui répond à l'intent INTENT_ACTION_TTS_SERVICE. La tâche principale d'un moteur de synthèse vocale intervient lors du rappel onSynthesizeText() dans un service qui étend TextToSpeechService. Le système fournit à cette méthode deux objets:

  • SynthesisRequest: contient diverses données, y compris le texte à synthétiser, les paramètres régionaux, le débit et le ton de la voix.
  • SynthesisCallback: interface par laquelle le moteur de synthèse vocale transmet les données vocales obtenues sous forme de flux audio. Le moteur doit d'abord appeler start() pour indiquer qu'il est prêt à diffuser le contenu audio, puis appeler audioAvailable(), en lui transmettant les données audio dans un tampon d'octets. Une fois que le moteur a transmis tout le contenu audio via le tampon, appelez done().

Maintenant que le framework est compatible avec une véritable API pour la création de moteurs de synthèse vocale, la prise en charge de l'implémentation du code natif a été supprimée. Recherchez un article de blog sur une couche de compatibilité que vous pouvez utiliser pour convertir vos anciens moteurs de synthèse vocale vers le nouveau framework.

Pour obtenir un exemple de moteur de synthèse vocale utilisant les nouvelles API, consultez l'application exemple Text-to-Speech.

Utilisation du réseau

Android 4.0 offre aux utilisateurs une visibilité précise sur la quantité de données réseau utilisées par leurs applications. L'application Paramètres fournit des commandes qui permettent aux utilisateurs de gérer les limites définies de l'utilisation des données réseau et même de désactiver l'utilisation des données en arrière-plan pour des applications individuelles. Pour éviter que les utilisateurs ne désactivent l'accès de votre application aux données en arrière-plan, vous devez développer des stratégies permettant d'utiliser efficacement la connexion de données et d'ajuster votre utilisation en fonction du type de connexion disponible.

Si votre application effectue de nombreuses transactions réseau, vous devez fournir des paramètres utilisateur permettant aux utilisateurs de contrôler leurs habitudes concernant les données, comme la fréquence à laquelle votre application synchronise les données, s'il faut effectuer des importations/téléchargements uniquement via le Wi-Fi, s'il doit utiliser des données en itinérance, etc. Ces commandes sont beaucoup moins susceptibles de désactiver l'accès de votre application aux données lorsqu'elles approchent de leurs limites, car ils peuvent contrôler précisément la quantité de données qu'elles peuvent utiliser. Si vous fournissez une activité de préférence avec ces paramètres, vous devez inclure un filtre d'intent pour l'action ACTION_MANAGE_NETWORK_USAGE dans la déclaration de son fichier manifeste. Par exemple :

<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>

Ce filtre d'intent indique au système qu'il s'agit de l'activité qui contrôle la consommation des données de votre application. Ainsi, lorsque l'utilisateur inspecte la quantité de données utilisées par votre application à partir de l'application Paramètres, un bouton "Afficher les paramètres de l'application" s'affiche et lance votre activité de préférences. Il peut ainsi affiner la quantité de données utilisée par votre application.

Notez également que getBackgroundDataSetting() est désormais obsolète et renvoie toujours la valeur "true". Utilisez plutôt getActiveNetworkInfo(). Avant d'effectuer des transactions réseau, vous devez toujours appeler getActiveNetworkInfo() pour obtenir le NetworkInfo qui représente le réseau actuel et interroger isConnected() pour vérifier si l'appareil dispose d'une connexion. Vous pouvez ensuite vérifier d'autres propriétés de connexion, par exemple si l'appareil est en itinérance ou connecté au Wi-Fi.

Grande entreprise

Android 4.0 étend les capacités des applications d'entreprise avec les fonctionnalités suivantes.

Services VPN

Le nouveau VpnService permet aux applications de créer leur propre VPN (réseau privé virtuel), qui s'exécute en tant que Service. Un service VPN crée une interface pour un réseau virtuel avec ses propres règles d'adresse et de routage, et effectue toutes les opérations de lecture et d'écriture à l'aide d'un descripteur de fichier.

Pour créer un service VPN, utilisez VpnService.Builder, qui vous permet de spécifier l'adresse réseau, le serveur DNS, la route réseau, etc. Une fois l'opération terminée, vous pouvez établir l'interface en appelant establish(), qui renvoie un ParcelFileDescriptor.

Étant donné qu'un service VPN peut intercepter des paquets, cela a des implications en termes de sécurité. Par conséquent, si vous implémentez VpnService, votre service doit exiger BIND_VPN_SERVICE pour garantir que seul le système peut s'y associer (seul le système dispose de cette autorisation ; les applications ne peuvent pas la demander). Pour utiliser ensuite votre service VPN, les utilisateurs doivent l'activer manuellement dans les paramètres système.

Règles relatives aux appareils

Les applications qui gèrent les restrictions liées aux appareils peuvent désormais désactiver la caméra à l'aide de setCameraDisabled() et de la propriété USES_POLICY_DISABLE_CAMERA (appliquée avec un élément <disable-camera /> dans le fichier de configuration des règles).

Gestion des certificats

La nouvelle classe KeyChain fournit des API qui vous permettent d'importer des certificats et d'y accéder dans le magasin de clés système. Les certificats simplifient l'installation des certificats clients (pour valider l'identité de l'utilisateur) et des certificats d'autorité de certification (pour vérifier l'identité du serveur). Les applications telles que les navigateurs Web ou les clients de messagerie peuvent accéder aux certificats installés pour authentifier les utilisateurs sur les serveurs. Pour en savoir plus, consultez la documentation KeyChain.

Capteurs d'appareil

Deux nouveaux types de capteurs ont été ajoutés dans Android 4.0:

Si un appareil est équipé à la fois de capteurs TYPE_AMBIENT_TEMPERATURE et TYPE_RELATIVE_HUMIDITY, vous pouvez les utiliser pour calculer le point de rosée et l'humidité absolue.

Le capteur de température précédent, TYPE_TEMPERATURE, a été abandonné. Utilisez plutôt le capteur TYPE_AMBIENT_TEMPERATURE.

De plus, les trois capteurs synthétiques d'Android ont été considérablement améliorés. Ils bénéficient désormais d'une latence plus faible et d'une sortie plus fluide. Ces capteurs incluent le capteur de gravité (TYPE_GRAVITY), le capteur de vecteur de rotation (TYPE_ROTATION_VECTOR) et le capteur d'accélération linéaire (TYPE_LINEAR_ACCELERATION). Les capteurs améliorés s'appuient sur le capteur du gyroscope pour améliorer leur sortie. Ils n'apparaissent donc que sur les appareils équipés d'un gyroscope.

Barre d'action

ActionBar a été mis à jour pour prendre en charge plusieurs nouveaux comportements. Plus important encore, le système gère de manière optimale la taille et la configuration de la barre d'action lorsqu'elle s'exécute sur des écrans plus petits, afin de fournir une expérience utilisateur optimale sur toutes les tailles d'écran. Par exemple, lorsque l'écran est étroit (par exemple, lorsqu'un téléphone est en mode portrait), les onglets de navigation de la barre d'action s'affichent dans une "barre empilée" qui apparaît directement sous la barre d'action principale. Vous pouvez également activer une "barre d'action fractionnée", qui place toutes les tâches dans une barre distincte en bas de l'écran lorsque celui-ci est étroit.

Barre d'action fractionnée

Si votre barre d'action comprend plusieurs tâches, elles ne rentrent pas toutes dans la barre d'action sur un écran étroit. Le système en place donc davantage dans le menu à développer. Cependant, Android 4.0 vous permet d'activer l'option "Diviser la barre d'action" afin que davantage d'actions puissent s'afficher dans une barre distincte en bas de l'écran. Pour activer la barre d'action fractionnée, ajoutez android:uiOptions avec "splitActionBarWhenNarrow" à votre balise <application> ou aux balises <activity> individuelles de votre fichier manifeste. Lorsque cette option est activée, le système ajoute une barre supplémentaire en bas de l'écran pour toutes les tâches lorsque celui-ci est étroit (aucune action n'apparaît dans la barre d'action principale).

Si vous souhaitez utiliser les onglets de navigation fournis par les API ActionBar.Tab, mais que vous n'avez pas besoin de la barre d'action principale en haut (vous souhaitez que seuls les onglets s'affichent en haut), activez la barre d'action fractionnée comme décrit ci-dessus. Appelez également setDisplayShowHomeEnabled(false) pour désactiver l'icône d'application dans la barre d'action. Il n'y a rien de plus dans la barre d'action principale, mais il disparaît. Il ne reste que les onglets de navigation en haut et les tâches en bas de l'écran.

Styles de la barre d'action

Si vous souhaitez appliquer un style personnalisé à la barre d'action, vous pouvez utiliser les nouvelles propriétés de style backgroundStacked et backgroundSplit pour appliquer un drawable ou une couleur d'arrière-plan à la barre empilée et à la barre de fractionnement, respectivement. Vous pouvez également définir ces styles lors de l'exécution avec setStackedBackgroundDrawable() et setSplitBackgroundDrawable().

Fournisseur d'actions

La nouvelle classe ActionProvider vous permet de créer un gestionnaire spécialisé pour les tâches. Un fournisseur d'actions peut définir une vue d'action, un comportement d'action par défaut et un sous-menu pour chaque élément d'action auquel il est associé. Lorsque vous souhaitez créer un élément d'action présentant des comportements dynamiques (tels qu'une vue d'action variable, une action par défaut ou un sous-menu), il est recommandé d'étendre ActionProvider afin de créer un composant réutilisable, au lieu de gérer les différentes transformations d'élément d'action dans votre fragment ou votre activité.

Par exemple, ShareActionProvider est une extension de ActionProvider qui facilite une action de partage depuis la barre d'action. Au lieu d'utiliser l'élément d'action traditionnel qui appelle l'intent ACTION_SEND, vous pouvez utiliser ce fournisseur d'action pour présenter une vue d'action avec une liste déroulante d'applications qui gèrent l'intent ACTION_SEND. Lorsque l'utilisateur sélectionne une application à utiliser pour l'action, ShareActionProvider mémorise cette sélection et la propose dans la vue des actions pour un accès plus rapide au partage avec cette application.

Pour déclarer un fournisseur d'actions pour une tâche, incluez l'attribut android:actionProviderClass dans l'élément <item> du menu d'options de votre activité, avec le nom de classe du fournisseur d'actions comme valeur. Par exemple :

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

Dans la méthode de rappel onCreateOptionsMenu() de votre activité, récupérez une instance du fournisseur d'action à partir de l'élément de menu et définissez l'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);
}

Pour obtenir un exemple d'utilisation de ShareActionProvider, consultez ActionBarShareActionProviderActivity dans ApiDemos.

Vues d'action réductibles

Les éléments d'action qui fournissent une vue d'action peuvent désormais basculer entre leur état de vue d'action et leur état traditionnel d'action. Auparavant, seul SearchView permettait le repli lorsqu'il était utilisé comme vue d'action. Vous pouvez désormais ajouter une vue d'action pour n'importe quelle action et basculer entre l'état développé (la vue des actions est visible) et l'état réduit (l'élément d'action est visible).

Pour déclarer qu'une tâche contenant une vue d'action peut être réduite, incluez l'indicateur “collapseActionView" dans l'attribut android:showAsAction de l'élément <item> dans le fichier XML du menu.

Pour recevoir des rappels lorsqu'une vue d'action passe de l'état développé à la vue réduite, enregistrez une instance de MenuItem.OnActionExpandListener avec le MenuItem correspondant en appelant setOnActionExpandListener(). En règle générale, vous devez effectuer cette opération lors du rappel onCreateOptionsMenu().

Pour contrôler une vue d'action réductible, vous pouvez appeler collapseActionView() et expandActionView() au niveau de l'élément MenuItem correspondant.

Lorsque vous créez une vue d'action personnalisée, vous pouvez également implémenter la nouvelle interface CollapsibleActionView pour recevoir des rappels lorsque la vue est développée et réduite.

Autres API pour la barre d'action

  • setHomeButtonEnabled() vous permet de spécifier si l'icône/le logo se comporte comme un bouton pour accéder à l'accueil ou vers le haut (passez "true" pour qu'il se comporte comme un bouton).
  • setIcon() et setLogo() vous permettent de définir l'icône ou le logo de la barre d'action au moment de l'exécution.
  • Fragment.setMenuVisibility() vous permet d'activer ou de désactiver la visibilité des éléments du menu d'options déclarés par le fragment. Cela est utile si le fragment a été ajouté à l'activité, mais qu'il n'est pas visible. Les éléments de menu doivent donc être masqués.
  • FragmentManager.invalidateOptionsMenu() vous permet d'invalider le menu d'options de l'activité lors de différents états du cycle de vie du fragment, dans lesquels l'utilisation de la méthode équivalente de Activity peut ne pas être disponible.

Interface utilisateur et vues

Android 4.0 introduit de nouvelles vues et d'autres composants d'interface utilisateur.

GridLayout

GridLayout est un nouveau groupe de vues qui place les vues enfants dans une grille rectangulaire. Contrairement à TableLayout, GridLayout repose sur une hiérarchie plate et n'utilise pas de vues intermédiaires telles que les lignes de table pour fournir la structure. Au lieu de cela, les enfants spécifient les lignes et les colonnes qu'ils doivent occuper (les cellules peuvent s'étendre sur plusieurs lignes et/ou colonnes). Par défaut, ils sont disposés de manière séquentielle sur les lignes et les colonnes de la grille. L'orientation GridLayout détermine si les enfants séquentiels sont disposés par défaut horizontalement ou verticalement. Vous pouvez spécifier l'espace entre les éléments enfants en utilisant des instances de la nouvelle vue Space ou en définissant les paramètres de marge pertinents sur les enfants.

Consultez ApiDemos pour des exemples d'utilisation de GridLayout.

TextureView

TextureView est une nouvelle vue qui vous permet d'afficher un flux de contenu, tel qu'une vidéo ou une scène OpenGL. Bien que semblable à SurfaceView, TextureView se distingue en ce sens qu'il se comporte comme une vue standard, au lieu de créer une fenêtre distincte. Vous pouvez donc le traiter comme n'importe quel autre objet View. Par exemple, vous pouvez appliquer des transformations, l'animer à l'aide de ViewPropertyAnimator ou ajuster son opacité avec setAlpha().

Notez que TextureView ne fonctionne que pendant une fenêtre avec accélération matérielle.

Pour en savoir plus, consultez la documentation TextureView.

Changer de widget

Le nouveau widget Switch est un bouton bascule à deux états que les utilisateurs peuvent faire glisser d'un côté ou de l'autre (ou simplement appuyer) pour basculer entre deux états.

Vous pouvez utiliser les attributs android:textOn et android:textOff pour spécifier le texte à afficher sur le bouton lorsque le paramètre est activé ou désactivé. L'attribut android:text vous permet également de placer un libellé à côté du commutateur.

Pour obtenir un exemple d'utilisation des commutateurs, consultez le fichier de mise en page switches.xml et l'activité Switches correspondante.

Android 3.0 a introduit PopupMenu pour créer des menus contextuels courts qui s'affichent à un point d'ancrage que vous spécifiez (généralement au niveau de l'élément sélectionné). Android 4.0 étend PopupMenu avec quelques fonctionnalités utiles:

  • Vous pouvez désormais gonfler facilement le contenu d'un menu pop-up à partir d'une ressource de menu XML avec inflate(), en lui transmettant l'ID de ressource de menu.
  • Vous pouvez également créer un PopupMenu.OnDismissListener qui reçoit un rappel lorsque le menu est fermé.

Préférences

Une nouvelle classe abstraite TwoStatePreference sert de base aux préférences offrant une option de sélection à deux états. Le nouveau SwitchPreference est une extension de TwoStatePreference qui fournit un widget Switch dans la vue des préférences pour permettre aux utilisateurs d'activer ou de désactiver un paramètre sans avoir à ouvrir un écran ou une boîte de dialogue de préférences supplémentaires. Par exemple, l'application Paramètres utilise un SwitchPreference pour les paramètres Wi-Fi et Bluetooth.

Thèmes système

Le thème par défaut de toutes les applications qui ciblent Android 4.0 (en définissant targetSdkVersion ou minSdkVersion sur “14" ou une version ultérieure) est désormais le thème par défaut de l'appareil: Theme.DeviceDefault. Il peut s'agir du thème Holo sombre ou d'un thème sombre différent défini par l'appareil en question.

Il est garanti que la famille de thèmes Theme.Holo ne change pas d'un appareil à l'autre lorsque la même version d'Android est exécutée. Si vous appliquez explicitement l'un des thèmes Theme.Holo à vos activités, vous pouvez être sûr qu'ils ne changeront pas de caractère sur différents appareils de la même version de la plate-forme.

Si vous souhaitez que votre application se fonde dans le thème général de l'appareil (par exemple, lorsque différents OEM fournissent différents thèmes par défaut pour le système), vous devez appliquer explicitement les thèmes de la famille Theme.DeviceDefault.

Bouton du menu d'options

À partir d'Android 4.0, vous remarquerez que les téléphones ne nécessitent plus le bouton matériel du menu. Toutefois, vous n'avez pas à vous en soucier si votre application existante fournit un menu d'options et s'attend à ce qu'il y ait un bouton Menu. Pour garantir que les applications existantes continuent de fonctionner comme prévu, le système propose un bouton Menu à l'écran pour les applications conçues pour les anciennes versions d'Android.

Pour une expérience utilisateur optimale, les applications nouvelles et mises à jour doivent plutôt utiliser ActionBar pour fournir un accès aux éléments de menu, et définir targetSdkVersion sur "14" afin de bénéficier des derniers comportements par défaut du framework.

Contrôles de la visibilité de l'UI du système

Depuis les débuts d'Android, le système gère un composant d'interface utilisateur appelé barre d'état, qui se trouve en haut des téléphones et fournit des informations telles que le signal de l'opérateur, l'heure, les notifications, etc. Android 3.0 a ajouté la barre système pour les tablettes, qui se trouve en bas de l'écran pour fournir des commandes de navigation système (Accueil, Retour, etc.), ainsi qu'une interface pour les éléments traditionnellement fournis par la barre d'état. Sous Android 4.0, le système fournit un nouveau type d'UI du système appelé barre de navigation. Vous pouvez considérer que la barre de navigation est une version réajustée de la barre système conçue pour les téléphones portables. Elle fournit des commandes de navigation pour les appareils qui n'ont pas d'équivalent matériel pour la navigation dans le système, mais elle n'affiche pas l'interface utilisateur de notification ni les commandes de configuration de la barre système. Ainsi, un appareil qui fournit la barre de navigation a également la barre d'état dans la partie supérieure.

À l'heure actuelle, vous pouvez masquer la barre d'état des téléphones à l'aide de l'indicateur FLAG_FULLSCREEN. Dans Android 4.0, les API qui contrôlent la visibilité de la barre système ont été mises à jour pour mieux refléter le comportement de la barre système et de la barre de navigation:

  • L'option SYSTEM_UI_FLAG_LOW_PROFILE remplace l'option STATUS_BAR_HIDDEN. Lorsqu'il est défini, cet indicateur active le mode "profil faible" pour la barre système ou la barre de navigation. Les boutons de navigation sont grisés et les autres éléments de la barre système sont également masqués. Son activation permet de créer des jeux plus immersifs sans distraire les boutons de navigation du système.
  • L'option SYSTEM_UI_FLAG_VISIBLE remplace l'option STATUS_BAR_VISIBLE pour demander que la barre système ou la barre de navigation soit visible.
  • SYSTEM_UI_FLAG_HIDE_NAVIGATION est un nouvel indicateur qui demande à masquer complètement la barre de navigation. Sachez que cela ne fonctionne que pour la barre de navigation utilisée par certains téléphones (elle ne masque pas la barre système sur les tablettes). La barre de navigation revient à l'affichage dès que le système reçoit une entrée utilisateur. Par conséquent, ce mode est principalement utile pour la lecture de vidéos ou pour d'autres cas où la totalité de l'écran est nécessaire, mais aucune entrée utilisateur n'est requise.

Vous pouvez définir chacun de ces indicateurs pour la barre système et la barre de navigation en appelant setSystemUiVisibility() sur n'importe quelle vue de votre activité. Le gestionnaire de fenêtres combine (OU) tous les indicateurs de toutes les vues de votre fenêtre et les applique à l'interface utilisateur du système tant que votre fenêtre est sélectionnée. Lorsque votre fenêtre n'est plus sélectionnée (l'utilisateur quitte votre application ou une boîte de dialogue s'affiche), vos indicateurs cessent de fonctionner. De même, si vous supprimez ces vues de la hiérarchie des vues, leurs indicateurs ne s'appliquent plus.

Pour synchroniser d'autres événements de votre activité dont la visibilité est modifiée sur l'UI du système (par exemple, masquer la barre d'action ou d'autres commandes d'interface utilisateur lorsque l'UI du système est masquée), vous devez enregistrer un View.OnSystemUiVisibilityChangeListener afin d'être averti lorsque la visibilité de la barre système ou de la barre de navigation change.

Consultez la classe OverscanActivity pour une démonstration des différentes options d'interface utilisateur du système.

Framework de saisie

Android 4.0 prend en charge les événements de pointage du curseur, ainsi que les nouveaux événements liés au stylet et au bouton de la souris.

Événements de pointage

La classe View prend désormais en charge les événements de survol pour permettre des interactions plus riches grâce à l'utilisation de dispositifs de pointeur (tels qu'une souris ou d'autres appareils exécutant un curseur à l'écran).

Pour recevoir des événements de pointage sur une vue, implémentez View.OnHoverListener et enregistrez-le avec setOnHoverListener(). Lorsqu'un événement de pointage se produit sur la vue, votre écouteur reçoit un appel à onHover(), en fournissant le View qui a reçu l'événement et un MotionEvent qui décrit le type d'événement de pointage qui s'est produit. Les événements de pointage peuvent être l'un des suivants:

Votre View.OnHoverListener doit renvoyer la valeur "true" à partir de onHover() s'il gère l'événement de pointage. Si votre écouteur renvoie la valeur "false", l'événement de pointage est envoyé comme d'habitude à la vue parent.

Si votre application utilise des boutons ou d'autres widgets dont l'apparence change en fonction de l'état actuel, vous pouvez désormais utiliser l'attribut android:state_hovered dans un drawable de liste d'états pour fournir un autre drawable d'arrière-plan lorsqu'un curseur pointe sur la vue.

Pour voir une démonstration des nouveaux événements de pointage, consultez la classe Hover dans ApiDemos.

Événements liés au stylet et au bouton de la souris

Android fournit désormais des API permettant de recevoir des entrées depuis un périphérique d'entrée de stylet, tel qu'un périphérique de tablette numériseur ou un écran tactile compatible avec un stylet.

La saisie au stylet fonctionne de la même manière que la saisie tactile ou à la souris. Lorsque le stylet est en contact avec le numériseur, les applications reçoivent des événements tactiles comme elles le feraient avec un doigt pour toucher l'écran. Lorsque le stylet pointe au-dessus du numériseur, les applications reçoivent des événements de pointage comme elles le feraient lorsque le pointeur de la souris était déplacé à l'écran lorsqu'aucun bouton n'est appuyé.

Votre application peut faire la distinction entre le doigt, la souris, le stylet et la gomme en interrogeant le "type d'outil" associé à chaque pointeur dans une MotionEvent à l'aide de getToolType(). Les types d'outils actuellement définis sont TOOL_TYPE_UNKNOWN, TOOL_TYPE_FINGER, TOOL_TYPE_MOUSE, TOOL_TYPE_STYLUS et TOOL_TYPE_ERASER. En interrogeant le type d'outil, votre application peut choisir de gérer la saisie au stylet de différentes manières, que ce soit avec le doigt ou la souris.

Votre application peut également demander sur quels boutons de la souris ou du stylet l'utilisateur appuie dessus en interrogeant l'état du bouton d'un MotionEvent à l'aide de getButtonState(). Les états du bouton actuellement définis sont les suivants: BUTTON_PRIMARY, BUTTON_SECONDARY, BUTTON_TERTIARY, BUTTON_BACK et BUTTON_FORWARD. Pour plus de commodité, les boutons "Précédent" et "Suivant" de la souris sont automatiquement mappés sur les touches KEYCODE_BACK et KEYCODE_FORWARD. Votre application peut gérer ces touches pour accepter la navigation avant et arrière à l'aide d'un bouton de la souris.

En plus de mesurer précisément la position et la pression d'un contact, certains périphériques d'entrée de stylet indiquent également la distance entre la pointe du stylet et le numériseur, l'angle d'inclinaison du stylet et l'angle d'orientation du stylet. Votre application peut interroger ces informations à l'aide de getAxisValue() avec les codes d'axe AXIS_DISTANCE, AXIS_TILT et AXIS_ORIENTATION.

Pour une démonstration des types d'outils, des états de bouton et des nouveaux codes d'axe, consultez la classe TouchPaint dans ApiDemos.

Propriétés

La nouvelle classe Property permet de spécifier rapidement, efficacement et facilement une propriété sur n'importe quel objet, qui permet aux appelants de définir/obtenir des valeurs de manière générique sur des objets cibles. Il permet également de transmettre des références de champ/de méthode et permet au code de définir/obtenir des valeurs de la propriété sans connaître les détails des champs/méthodes.

Par exemple, si vous souhaitez définir la valeur du champ bar sur l'objet foo, procédez comme suit:

Kotlin

foo.bar = value

Java

foo.bar = value;

Si vous souhaitez appeler le setter pour un champ privé sous-jacent bar, procédez comme suit:

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

Toutefois, si vous souhaitez transmettre l'instance foo et faire en sorte qu'un autre code définisse la valeur bar, il n'y a vraiment aucun moyen de le faire avant Android 4.0.

À l'aide de la classe Property, vous pouvez déclarer un objet Property BAR sur la classe Foo afin de définir le champ sur l'instance foo de la classe Foo comme suit:

Kotlin

BAR.set(foo, value)

Java

BAR.set(foo, value);

La classe View exploite désormais la classe Property pour vous permettre de définir divers champs, comme les propriétés de transformation ajoutées dans Android 3.0 (ROTATION, ROTATION_X, TRANSLATION_X, etc.).

La classe ObjectAnimator utilise également la classe Property. Vous pouvez donc créer une ObjectAnimator avec un Property, ce qui est plus rapide, plus efficace et plus sûr que l'approche basée sur des chaînes.

Accélération matérielle

À partir d'Android 4.0, l'accélération matérielle pour toutes les fenêtres est activée par défaut si votre application a défini targetSdkVersion ou minSdkVersion sur “14" ou une version ultérieure. L'accélération matérielle se traduit généralement par des animations et un défilement plus fluides, ainsi que par de meilleures performances globales et une meilleure réponse à l'interaction de l'utilisateur.

Si nécessaire, vous pouvez désactiver manuellement l'accélération matérielle avec l'attribut hardwareAccelerated pour des éléments <activity> individuels ou l'élément <application>. Vous pouvez également désactiver l'accélération matérielle pour des vues individuelles en appelant setLayerType(LAYER_TYPE_SOFTWARE).

Pour en savoir plus sur l'accélération matérielle, y compris pour obtenir la liste des opérations de dessin non compatibles, consultez le document Accélération matérielle.

Modifications JNI

Dans les versions précédentes d'Android, les références locales JNI n'étaient pas des identifiants indirects. Android utilisait des pointeurs directs. Cela n'était pas un problème tant que le récupérateur de mémoire ne déplaçait pas les objets, mais il semblait fonctionner, car il permettait d'écrire du code présentant des bugs. Sous Android 4.0, le système utilise désormais des références indirectes pour détecter ces bugs.

Tout savoir sur les références locales JNI est décrit dans la section "Local and Global References" (Références locales et globales) dans les conseils sur JNI. Dans Android 4.0, CheckJNI a été amélioré pour détecter ces erreurs. Consultez le blog des développeurs Android pour consulter un article à venir sur les erreurs courantes liées aux références JNI et sur la façon de les corriger.

Cette modification de l'implémentation JNI n'affecte que les applications qui ciblent Android 4.0 en définissant targetSdkVersion ou minSdkVersion sur “14" ou une version ultérieure. Si vous avez défini ces attributs sur une valeur inférieure, les références locales JNI se comportent de la même manière que dans les versions précédentes.

WebKit

  • WebKit mis à jour vers la version 534.30
  • Prise en charge des polices indiennes (devanagari, bengali et tamoul, y compris la prise en charge des caractères complexes nécessaire pour combiner des glyphes) dans WebView et dans le navigateur intégré.
  • Prise en charge des polices éthiopiennes, géorgiennes et arméniennes dans WebView et dans le navigateur intégré.
  • La compatibilité avec WebDriver vous permet de tester plus facilement les applications qui utilisent WebView.

Navigateur Android

Le navigateur ajoute les fonctionnalités suivantes pour prendre en charge les applications Web:

Autorisations

Voici les nouvelles autorisations:

Fonctionnalités de l'appareil

Voici les nouvelles fonctionnalités de l'appareil:

  • FEATURE_WIFI_DIRECT: indique que l'application utilise le Wi-Fi pour les communications peer-to-peer.

Pour obtenir une vue détaillée de toutes les modifications apportées à l'API dans Android 4.0 (niveau d'API 14), consultez le rapport sur les différences entre les API.

API précédentes

En plus de tout ce qui précède, Android 4.0 est naturellement compatible avec toutes les API des versions précédentes. Étant donné que la plate-forme Android 3.x n'est disponible que pour les appareils à grand écran, si vous avez principalement développé des applications pour des téléphones portables, vous ne connaissez peut-être pas toutes les API ajoutées à Android dans ces versions récentes.

Voici quelques-unes des API les plus importantes que vous avez peut-être manquées et qui sont désormais disponibles sur les téléphones:

Android 3.0
  • Fragment: composant de framework qui vous permet de séparer les éléments distincts d'une activité en modules autonomes qui définissent leur propre interface utilisateur et leur propre cycle de vie. Consultez le guide du développeur Fragments.
  • ActionBar: remplacement de la barre de titre traditionnelle en haut de la fenêtre de l'activité. Elle inclut le logo de l'application dans le coin gauche et fournit une nouvelle interface pour les éléments de menu. Consultez le guide du développeur sur la barre d'action.
  • Loader: composant de framework qui facilite le chargement asynchrone des données, combiné à des composants d'interface utilisateur, pour charger les données de manière dynamique sans bloquer le thread principal. Consultez le guide du développeur sur les chargeurs.
  • Presse-papiers système: les applications peuvent copier et coller des données (au-delà du simple texte) vers et depuis le presse-papiers du système. Les données rognées peuvent être du texte brut, un URI ou un intent. Consultez le guide du développeur Copier et coller.
  • Glisser-déposer: ensemble d'API intégrées au framework d'affichage qui facilite les opérations de glisser-déposer. Consultez le guide du développeur Glisser-déposer.
  • Un tout nouveau framework d'animation flexible vous permet d'animer les propriétés arbitraires de n'importe quel objet (vue, drawable, fragment, objet ou tout autre élément) et de définir des aspects d'animation tels que la durée, l'interpolation, la répétition, etc. Le nouveau framework rend les animations sous Android plus simples que jamais. Consultez le guide du développeur Animation des propriétés.
  • Graphiques et Compute Engine RenderScript: RenderScript offre une API de rendu et de calcul de graphismes 3D hautes performances au niveau natif, que vous écrivez en C (standard C99). Vous bénéficiez ainsi des performances que vous attendez d'un environnement natif tout en restant portable sur différents processeurs et GPU. Consultez le guide du développeur RenderScript.
  • Graphiques 2D avec accélération matérielle: vous pouvez désormais activer le moteur de rendu OpenGL pour votre application en définissant {android:hardwareAccelerated="true"} dans l'élément <application> de votre élément manifeste ou pour des éléments <activity> individuels. Cela se traduit par des animations et un défilement plus fluides, ainsi que par de meilleures performances globales et une meilleure réponse à l'interaction de l'utilisateur.

    Remarque:Si vous définissez minSdkVersion ou targetSdkVersion sur "14" ou une version ultérieure, l'accélération matérielle est activée par défaut.

  • et bien plus encore. Pour en savoir plus, consultez les notes sur la plate-forme Android 3.0.
Android 3.1
  • API USB: nouvelles API puissantes pour intégrer des périphériques connectés aux applications Android. Les API reposent sur une pile USB et des services intégrés à la plate-forme. Elles prennent également en charge les interactions entre hôtes et appareils USB. Consultez le guide du développeur Hôte et accessoires USB.
  • API MTP/PTP: les applications peuvent interagir directement avec les caméras connectées et d'autres appareils PTP pour recevoir des notifications lorsque des appareils sont connectés et supprimés, gérer les fichiers et le stockage sur ces appareils, et transférer des fichiers et des métadonnées vers et depuis ces appareils. L'API MTP met en œuvre le sous-ensemble PTP (Picture Transfer Protocol) de la spécification MTP (Media Transfer Protocol). Consultez la documentation android.mtp.
  • API RTP: Android expose une API à sa pile RTP (Real-time Transport Protocol) intégrée, que les applications peuvent utiliser pour gérer le flux de données interactif ou à la demande. En particulier, les applications qui proposent des fonctionnalités de VoIP, de push pour discuter, de conférence et de streaming audio peuvent utiliser l'API pour lancer des sessions et transmettre ou recevoir des flux de données sur n'importe quel réseau disponible. Consultez la documentation android.net.rtp.
  • Prise en charge des joysticks et autres entrées de mouvement génériques.
  • Consultez les notes de la plate-forme Android 3.1 pour de nombreuses nouvelles API.
Android 3.2
  • Les nouveaux écrans prennent en charge des API qui vous permettent de mieux contrôler l'affichage de vos applications sur différentes tailles d'écran. L'API étend le modèle existant de prise en charge des écrans en permettant de cibler avec précision des plages de tailles d'écran spécifiques en fonction des dimensions, mesurées en unités de pixels indépendantes de la densité (telles que 600 dp ou 720 dp de large), plutôt que par leurs tailles d'écran généralisées (grandes ou très grandes). Par exemple, cette information est importante pour vous aider à faire la distinction entre un appareil de 5 pouces et un appareil de 7 pouces, qui sont traditionnellement répartis sur plusieurs écrans. Consultez l'article de blog New Tools for Managing Screen Sizes (Nouveaux outils pour gérer les tailles d'écran).
  • Nouvelles constantes pour <uses-feature> afin de déclarer les exigences d'orientation de l'écran en mode paysage ou portrait
  • La configuration de la "taille de l'écran" de l'appareil change désormais lors d'un changement d'orientation de l'écran. Si votre application cible le niveau d'API 13 ou supérieur, vous devez gérer la modification de la configuration de "screenSize" si vous souhaitez également gérer la modification de la configuration de "orientation". Pour en savoir plus, consultez android:configChanges.
  • Consultez les notes sur la plate-forme Android 3.2 pour d'autres nouvelles API.

Niveau d'API

L'API Android 4.0 se voit attribuer un identifiant entier (14) stocké dans le système. Cet identifiant, appelé "niveau d'API", permet au système de déterminer correctement si une application est compatible avec le système, avant de l'installer.

Pour utiliser les API introduites dans Android 4.0 dans votre application, vous devez compiler l'application sur une plate-forme Android compatible avec le niveau d'API 14 ou supérieur. En fonction de vos besoins, vous devrez peut-être également ajouter un attribut android:minSdkVersion="14" à l'élément <uses-sdk>.

Pour en savoir plus, consultez Qu'est-ce que le niveau d'API ?