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é dansMAX_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:
Events.TITLE
: nom de l'événementCalendarContract.EXTRA_EVENT_BEGIN_TIME
: heure de début de l'événement, en millisecondes, à partir de l'epochCalendarContract.EXTRA_EVENT_END_TIME
: heure de fin de l'événement, en millisecondes, à partir de l'epochEvents.EVENT_LOCATION
: lieu de l'événementEvents.DESCRIPTION
: description de l'événementIntent.EXTRA_EMAIL
: adresses e-mail des personnes invitéesEvents.RRULE
: règle de récurrence de l'événement.Events.ACCESS_LEVEL
: événement public ou privéEvents.AVAILABILITY
: indique si la période de cet événement permet de planifier d'autres événements au même moment.
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:
- Elles doivent être liées à une image de texture
GL_TEXTURE_2D
. - 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:
- Appelez
EffectContext.createWithCurrentGlContext()
à partir de votre contexte OpenGL ES 2.0. - Utilisez le
EffectContext
renvoyé pour appelerEffectContext.getFactory()
, qui renvoie une instance deEffectFactory
. - Appelez
createEffect()
en lui transmettant un nom d'effet à partir de @link android.media.effect.EffectFactory}, tel queEFFECT_FISHEYE
ouEFFECT_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'autorisationINTERNET
. Si vous utilisezMediaPlayer
pour lire du contenu à partir d'Internet, veillez à ajouter l'autorisationINTERNET
à votre fichier manifeste. Sinon, la lecture de contenus multimédias ne fonctionnera pas à partir d'Android 4.0. setSurface()
vous permet de définir uneSurface
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, appelezisVideoSnapshotSupported()
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()
etsetAutoWhiteBalanceLock()
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 votreNdefMessage
lors de la méthodeonCreate()
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 envoieNdefMessage
à 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éthodecreateNdefMessage()
renvoie leNdefMessage
que vous souhaitez envoyer. Transmettez ensuite l'implémentation deNfcAdapter.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 leNdefMessage
que vous souhaitez envoyer. Cela vous permet de définirNdefMessage
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 bien 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 unWifiP2pDeviceList
, à partir duquel vous pouvez récupérer un objetWifiP2pDevice
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 objetWifiP2pGroup
, 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 objetWifiP2pInfo
, 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:
WIFI_P2P_CONNECTION_CHANGED_ACTION
: l'état de la connexion P2P a changé. Elle contientEXTRA_WIFI_P2P_INFO
avec un objetWifiP2pInfo
etEXTRA_NETWORK_INFO
avec un objetNetworkInfo
.WIFI_P2P_STATE_CHANGED_ACTION
: l'état P2P est passé de "Activé" à "Désactivé". Elle contientEXTRA_WIFI_STATE
avecWIFI_P2P_STATE_DISABLED
ouWIFI_P2P_STATE_ENABLED
.WIFI_P2P_PEERS_CHANGED_ACTION
: la liste des appareils similaires a été modifiée.WIFI_P2P_THIS_DEVICE_CHANGED_ACTION
: les détails de cet appareil ont changé.
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 à votreBluetoothHealthCallback
, 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 APIBluetoothHealth
.
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:
- Lorsqu'elles sont appelées, les méthodes
sendAccessibilityEvent()
etsendAccessibilityEventUnchecked()
s'appliquent àonInitializeAccessibilityEvent()
.Les implémentations personnalisées de
View
peuvent souhaiter implémenteronInitializeAccessibilityEvent()
pour joindre des informations d'accessibilité supplémentaires auAccessibilityEvent
, 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. - 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 rappelonPopulateAccessibilityEvent()
.Les implémentations personnalisées de
View
doivent généralement implémenteronPopulateAccessibilityEvent()
pour ajouter du contenu textuel supplémentaire àAccessibilityEvent
si le texteandroid:contentDescription
est manquant ou insuffisant. Pour ajouter une description textuelle àAccessibilityEvent
, appelezgetText()
.add()
. - À ce stade,
View
fait remonter l'événement dans la hiérarchie des vues en appelantrequestSendAccessibilityEvent()
sur la vue parente. Chaque vue parent a ensuite la possibilité d'améliorer les informations d'accessibilité en ajoutant unAccessibilityRecord
, jusqu'à ce qu'elle atteigne la vue racine, ce qui envoie l'événement àAccessibilityManager
avecsendAccessibilityEvent()
.
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:
- Lorsque vous recevez un
AccessibilityEvent
d'une application, appelezAccessibilityEvent.getRecord()
pour récupérer unAccessibilityRecord
spécifique (plusieurs enregistrements peuvent être associés à l'événement). - À partir de
AccessibilityEvent
ou d'unAccessibilityRecord
individuel, vous pouvez appelergetSource()
pour récupérer un objetAccessibilityNodeInfo
.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'objetAccessibilityNodeInfo
renvoyé parAccessibilityEvent
décrit la source de l'événement, tandis que la source d'unAccessibilityRecord
décrit le prédécesseur de la source de l'événement. - Avec
AccessibilityNodeInfo
, vous pouvez interroger des informations à son sujet, appelergetParent()
ougetChild()
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:
AccessibilityManager.AccessibilityStateChangeListener
est une interface qui vous permet de recevoir un rappel chaque fois que l'accessibilité est activée ou désactivée.getEnabledAccessibilityServiceList()
fournit des informations sur les services d'accessibilité actuellement activés.isTouchExplorationEnabled()
vous indique si le mode d'exploration au toucher est activé.
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 appelerstart()
pour indiquer qu'il est prêt à diffuser le contenu audio, puis appeleraudioAvailable()
, 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, appelezdone()
.
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:
TYPE_AMBIENT_TEMPERATURE
: capteur de température qui fournit la température ambiante (pièce) en degrés Celsius.TYPE_RELATIVE_HUMIDITY
: capteur d'humidité indiquant l'humidité ambiante relative (pièce) en pourcentage.
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()
etsetLogo()
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 deActivity
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.
Menus pop-up
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'optionSTATUS_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'optionSTATUS_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:
- Mise à jour du compilateur JavaScript V8 pour des performances plus rapides
- De plus, d'autres améliorations notables transférées depuis Android 3.0 sont désormais disponibles pour les téléphones :
- Prise en charge des éléments à position fixe sur toutes les pages
- Capture multimédia HTML
- Événements d'orientation de l'appareil
- Transformations 3D CSS
Autorisations
Voici les nouvelles autorisations:
ADD_VOICEMAIL
: autorise un service de messagerie vocale à ajouter des messages vocaux à l'appareil.BIND_TEXT_SERVICE
: un service qui implémenteSpellCheckerService
doit avoir besoin de cette autorisation.BIND_VPN_SERVICE
: un service qui implémenteVpnService
doit avoir besoin de cette autorisation.- android.Manifest.permission#READ_PROFILE: fournit un accès en lecture au fournisseur
ContactsContract.Profile
. - android.Manifest.permission#WRITE_PROFILE: fournit un accès en écriture au fournisseur
ContactsContract.Profile
.
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
outargetSdkVersion
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, consultezandroid: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 ?