API Android 4.0

Niveau d'API:14

Android 4.0 (ICE_CREAM_SANDWICH) est une version majeure de la plate-forme qui ajoute de nombreuses nouvelles fonctionnalités pour les utilisateurs et les développeurs d'applications. En plus de toutes les nouvelles fonctionnalités et API décrites ci-dessous, Android 4.0 est une version de plate-forme importante, car elle apporte l'ensemble étendu d'API et de thèmes holographiques d'Android 3.x aux é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 permet de développer et de publier votre application avec un seul APK qui offre une expérience utilisateur optimisée pour les téléphones, les tablettes, etc., lorsqu'ils exécutent 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 sous la forme un 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 avec Android 4.0, utilisez Android SDK Manager pour télécharger la plate-forme dans votre SDK.

Présentation de l'API

Les sections ci-dessous présentent un aperçu technique des nouvelles API d'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 à des 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, tel que défini par le ContactsContract.Profile. Les applications de réseau social qui gèrent une identité utilisateur peuvent contribuer aux données de profil de l'utilisateur en créant une entrée ContactsContract.RawContacts dans ContactsContract.Profile. Autrement dit, les contacts bruts qui représentent l'utilisateur de l'appareil n'appartiennent pas au tableau de contacts bruts traditionnel défini par l'URI ContactsContract.RawContacts. Vous devez plutôt ajouter un contact brut de profil dans le tableau à CONTENT_RAW_CONTACTS_URI. Brut les contacts de ce tableau sont ensuite regroupés dans un seul profil visible par l'utilisateur intitulé "Moi".

L'ajout d'un contact brut pour le profil nécessite le Autorisation android.Manifest.permission#WRITE_PROFILE. De même, pour lire à partir de la table de profils, 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 y ajoutent des données. La lecture du profil utilisateur est une autorisation sensible, et vous devez vous attendre à ce que les utilisateurs soient sceptiques vis-à-vis 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'invitation l'utilise pour inviter le contact spécifié à rejoindre ce réseau social. La plupart des applications seront côté réception de cette opération. Par exemple, l'application Personnes 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 listée dans les coordonnées d'une personne.

Pour rendre votre application visible comme dans "Ajouter une connexion" votre application doit fournir un adaptateur de synchronisation synchroniser les informations de contact à partir de vos réseaux sociaux. 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 un 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 les tâches nécessaires pour inviter ce contact au réseau ou ajouter la personne aux connexions de l'utilisateur.

Photos volumineuses

Android est désormais compatible avec les photos haute résolution pour les contacts. Désormais, lorsque vous insérez une photo dans un enregistrement de contact, le système la traite en tant que vignette 96x96 (comme auparavant) et en tant que "photo d'affichage" 256x256 stockée dans un nouveau magasin de photos basé sur des fichiers (les dimensions exactes choisies par le système peuvent varier à l'avenir). Pour ajouter une grande photo à un contact, placez une grande photo figurant dans la colonne habituelle (PHOTO) ligne de données, que le système traite ensuite pour créer la vignette et la photo d'affichage appropriées d'enregistrements.

Commentaires sur l'utilisation des contacts

Les nouvelles API ContactsContract.DataUsageFeedback vous permettent de suivre La fréquence à laquelle l'utilisateur a recours à des méthodes spécifiques pour contacter des personnes, comme 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 contact associée à chaque personne et fournir de meilleures suggestions pour contacter chaque personne.

Fournisseur d'agenda

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

Divers widgets et applications peuvent utiliser ces API pour lire et modifier des événements d'agenda. Toutefois, certains des cas d'utilisation les plus intéressants 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. Par exemple, les événements Google Agenda 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 le suivant : défini par CalendarContract. Toutes les données d'agenda de l'utilisateur sont stockées Nombre de tables définies par différentes sous-classes de CalendarContract:

  • La table CalendarContract.Calendars contient les informations spécifiques au calendrier. Chaque ligne de ce tableau contient les détails d'un seul agenda, tels que son nom, la couleur, les informations de synchronisation, etc.
  • La table CalendarContract.Events contient des informations spécifiques à l'événement. Chaque ligne de ce tableau contient les informations relatives à un seul événement, comme le titre de l'événement, le lieu, l'heure de début, l'heure de fin, etc. L'événement peut se produire une seule 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 Utilisez le _ID de l'événement pour l'associer à l'événement.
  • La table CalendarContract.Instances contient l'heure de début et de fin des occurrences d'un événement. Chaque ligne de ce tableau représente une seule occurrence. Pour les événements ponctuels, il existe un mappage individuel des instances aux événements. Pour les événements périodiques, automatiquement généré pour correspondre aux multiples occurrences de cet événement.
  • La table CalendarContract.Attendees contient le participant ou l'invité à l'événement. des informations. Chaque ligne représente un seul invité d'un événement. Il spécifie le type d'invité et la réponse de la personne à l'événement.
  • La table CalendarContract.Reminders contient les données d'alerte/notification. Chaque ligne représente une alerte unique pour un événement. Un événement peut avoir plusieurs rappels. Le nombre de les rappels par événement sont spécifiés dans MAX_REMINDERS, qui est défini par l'adaptateur de synchronisation qui est propriétaire de l'agenda donné. Les rappels sont spécifiés en nombre de minutes avant que l'événement ne soit programmée et définir une méthode d'alarme (par exemple, utilisation d'une alerte, d'un e-mail ou d'un SMS pour l'utilisateur.
  • La table CalendarContract.ExtendedProperties contient des champs de données opaques utilisés par l'adaptateur de synchronisation. Le fournisseur n'effectue aucune action sur les éléments de ce tableau, sauf pour les supprimer lorsque les événements associés sont supprimés.

Pour accéder aux données d'agenda d'un utilisateur avec le fournisseur d'agenda, 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 une de l'application Agenda pour créer des événements. L'utilisation de l'intent ne nécessite aucune et spécifier les détails de l'événement à l'aide des 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, un utilisateur peut disposer de plusieurs sources de messagerie vocale, telles que l'une auprès du fournisseur de services du téléphone, et les autres via la fonctionnalité VoIP ou une autre voix services. Ces applications peuvent utiliser les API Voicemail Provider pour ajouter leurs messages vocaux sur l'appareil. L'application Téléphone intégrée présente ensuite tous les messages vocaux à l'utilisateur de manière unifiée. Bien que l'application Téléphone du système soit la seule à pouvoir lire tous les messages vocaux, chaque application qui fournit des messages vocaux peut lire ceux qu'elle a ajoutés au système (mais pas les messages vocaux d'autres services).

Étant donné que les API n'autorisent pas actuellement 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 des messages vocaux à transmettre à l'utilisateur.

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

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 aux images et vidéos. Par exemple, les effets sur les images vous permettent de corriger facilement les yeux rouges, de convertir une image en nuances de gris, ajuster la luminosité, ajuster la saturation, faire pivoter une image, appliquer un effet fisheye et bien plus encore. Le système effectue tout le traitement des effets sur le GPU pour obtenir des performances maximales.

Pour des performances maximales, 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. Textures auxquelles vous appliquez peuvent provenir de bitmaps, de vidéos ou même de l'appareil photo. Cependant, certaines restrictions les textures doivent respecter:

  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 un 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. sur EffectFactory.
  3. Appelez createEffect() en lui transmettant une nom de l'effet de @link android.media.effect.EffectFactory}, par exemple 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.

Tous les effets listés dans EffectFactory sont compatibles. 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é depuis la bibliothèque externe est pris en charge en appelant isEffectSupported()

Client de contrôle à distance

La nouvelle 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 exposer des informations sur le contenu multimédia en cours de lecture à afficher sur la télécommande, telles que des informations sur le titre et la pochette de l'album.

Pour activer les clients de contrôle à distance 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 commande 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é lorsque vous avez instancié RemoteControlClient recevra des événements ACTION_MEDIA_BUTTON lorsqu'un bouton est enfoncé à partir d'une télécommande. L'intent que vous recevez inclut le KeyEvent pour la touche multimédia enfoncé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 concernant le contenu multimédia en cours de lecture, appelez editMetaData() et ajoutez des métadonnées au fichier renvoyé RemoteControlClient.MetadataEditor Vous pouvez fournir un bitmap pour l'illustration multimédia, des informations numériques telles que le temps écoulé et des informations textuelles telles que le titre du titre. Pour en savoir plus sur les clés disponibles, consultez les options METADATA_KEY_* dans MediaMetadataRetriever.

Pour voir un exemple d'implémentation, consultez la page sur Random Music Player, qui fournit une logique de compatibilité qui active le client de commande à distance sur Android 4.0 appareils, tout en continuant à prendre en charge les appareils fonctionnant sous 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 depuis Internet, veillez à ajouter l'autorisation INTERNET à votre fichier manifeste, sinon la lecture multimédia ne fonctionnera pas à partir d'Android 4.0.
  • setSurface() vous permet de définir un Surface pour qu'il se comporte comme un puits vidéo.
  • setDataSource() vous permet d'effectuer les actions suivantes : envoyer des en-têtes HTTP supplémentaires avec votre requête, ce qui peut être utile pour le streaming HTTP(S) en direct
  • La diffusion en direct HTTP(S) respecte désormais les cookies HTTP dans les requêtes

Types de supports

Android 4.0 est désormais compatible avec les fonctionnalités suivantes:

  • Version 3 du protocole HTTP/HTTPS Live Streaming
  • Encodage audio AAC brut ADTS
  • Images WEBP
  • Vidéo Matroska

Pour en savoir plus, consultez la page Supports compatibles Formats.

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 fonctionnalités grâce aux API de détection de visages d'Android, qui ne détectent que le visage d'un sujet, mais aussi des caractéristiques faciales spécifiques, comme les yeux et la bouche.

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

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

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

  • Élément Rect spécifiant les limites du visage par rapport à la champ de vision actuel
  • Nombre entier compris entre 1 et 100 indiquant le niveau de confiance du système quant à l'identification de l'objet comme un visage humain
  • Un identifiant unique pour suivre plusieurs visages
  • Plusieurs objets Point indiquant la position des yeux et de la bouche localisé

Remarque : La détection des visages n'est peut-être 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. De plus, il est possible que certains appareils ne prennent pas en charge l'identification des yeux et de la bouche. Dans ce cas, ces champs de l'objet Camera.Face seront nuls.

Zones de mise au point et de mesure

Les applis d'appareil photo peuvent désormais contrôler les zones que l'appareil photo utilise pour la mise au point et la mesure du blanc solde et l'exposition automatique. Les 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 le poids de la zone (qui représente le niveau d'importance de cette zone par rapport aux autres zones prises en compte) avec un entier.

Avant de définir une zone de mise au point ou une zone de mesure, vous devez d'abord appeler respectivement getMaxNumFocusAreas() ou getMaxNumMeteringAreas(). Si ces valeurs 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, appelez simplement setFocusAreas() ou setMeteringAreas(). Chacune prend un 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 le paramètre en appuyant sur une zone de l'aperçu, que vous traduisez ensuite en un objet Camera.Area et demandez que la caméra effectue 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 dans cette zone change.

Mise au point automatique continue pour les photos

Vous pouvez désormais activer la mise au point automatique en continu lorsque vous prenez des photos. Pour activer CAF dans votre appli d'appareil photo, transmettre FOCUS_MODE_CONTINUOUS_PICTURE à setFocusMode(). Lorsque vous êtes prêt à prendre des photos une photo, appelez autoFocus(). Votre Camera.AutoFocusCallback reçoit immédiatement un rappel pour indiquer si l’objectif était atteint. Pour reprendre la 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 de vidéos à l'aide de FOCUS_MODE_CONTINUOUS_VIDEO, qui a été ajoutée au niveau d'API 9.

Autres fonctionnalités de l'appareil photo

  • Lors d'un enregistrement vidéo, vous pouvez désormais appeler takePicture() pour sauvegarder une photo sans interrompre la session vidéo. Avant de le faire, vous devez appelez isVideoSnapshotSupported() pour vous assurer que le matériel le prend en charge.
  • Vous pouvez désormais verrouiller l'exposition automatique et la balance des blancs avec setAutoExposureLock() et setAutoWhiteBalanceLock() pour empêcher la modification de ces propriétés.
  • Vous pouvez désormais appeler setDisplayOrientation() pendant l'exécution de l'aperçu de l'appareil photo. Auparavant, vous ne pouviez appeler cette méthode qu'avant de commencer 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 avoir pris une photo.
  • 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 capturé 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 (un processus également appelé "NDEF Push"). Le transfert de données est lancé lorsque deux Les appareils Android compatibles avec Android Beam se trouvent à proximité (environ 4 cm), généralement avec le dos en touchant. Les données du message NDEF peuvent contenir toutes les données que vous souhaitez partager entre les appareils. Par exemple, l'application Contacts partage les contacts, YouTube partage les vidéos et le navigateur partage les 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 au premier plan. Vous devez ensuite transmettre le NdefMessage au système de l'une des deux manières suivantes :

  • Définissez un seul NdefMessage à transmettre 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 l'événement onCreate() de votre activité. . Ensuite, chaque fois qu'Android Beam est activé avec un autre appareil lorsque l'activité est au premier plan, le système envoie le 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, lorsqu'Android Beam est activé sur un autre appareil alors que votre activité est dans le 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 diffusé qu'une seule fois lorsque Android Beam est lancé, au cas où le contenu du message pourrait varier tout au long de la durée de vie de l'activité.

Si vous souhaitez exécuter du code spécifique une fois que le système a envoyé votre message NDEF à l'autre appareil, vous pouvez implémenter NfcAdapter.OnNdefPushCompleteCallback et le définir avec setNdefPushCompleteCallback(). Le système appelle ensuite onNdefPushComplete() lorsque le message est envoyé.

Sur l'appareil destinataire, 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 ACTION_NDEF_DISCOVERED. pour démarrer une activité, avec une URL ou un type MIME défini en fonction du premier NdefRecord dans le NdefMessage. Pour l'activité à laquelle vous souhaitez répondre, vous pouvez déclarer des filtres d'intent pour les URL ou les types MIME qui intéressent votre application. Pour en savoir plus sur la distribution des tags, consultez le guide du développeur NFC.

Si vous souhaitez que votre NdefMessage comporte un URI, vous pouvez maintenant utiliser la fonction pratique La méthode createUri pour construire un nouveau NdefRecord basé sur une chaîne ou un objet Uri. Si l'URI est un format spécial que vous souhaitez que votre application reçoive également 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 pour vous assurer 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(), 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 transmet 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, utilise l'enregistrement d'application Android pour lancer Google Play et diriger l'utilisateur vers le pour 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 une Enregistrement d'application Android qui identifie votre application. Si l'appareil récepteur dispose du application installée, le système la lance ; s'il n'est pas installé, Google Play s'ouvre l'utilisateur à votre application pour l'installer.

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

Wi-Fi P2P

Android prend désormais en charge les connexions Wi-Fi peer-to-peer (P2P) entre les appareils Android et Autres types d'appareils (conformément aux normes Wi-Fi DirectTM de la Wi-Fi Alliance de certification) 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 et de vous connecter à d'autres appareils lorsque chacun d'eux est compatible avec le Wi-Fi P2P, puis de communiquer via 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 point à point avec le Wi-Fi. La classe principale avec laquelle vous devez travailler est WifiP2pManager, que vous pouvez acquérir en appelant getSystemService(WIFI_P2P_SERVICE). WifiP2pManager inclut des API qui vous permettent d'effectuer les opérations suivantes :

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

D'autres interfaces et classes sont également nécessaires, telles que:

  • L'interface WifiP2pManager.ActionListener vous permet de recevoir des rappels lorsqu'une opération telle que la découverte de pairs ou la connexion à eux aboutit ou échoue.
  • L'interface WifiP2pManager.PeerListListener vous permet de recevoir des informations sur les pairs détectés. 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, l'adresse, le type d'appareil, les configurations WPS compatibles, etc.
  • L'interface WifiP2pManager.GroupInfoListener vous permet d'effectuer les actions suivantes : recevoir des informations sur un groupe P2P. Le rappel fournit un objet WifiP2pGroup, qui fournit des informations sur le groupe, telles que le propriétaire, le nom du réseau et la phrase de passe.
  • L'interface WifiP2pManager.ConnectionInfoListener vous permet d'effectuer les actions suivantes : recevoir des informations sur la connexion actuelle. Le rappel fournit un objet WifiP2pInfo, qui contient des informations telles que si un groupe a été et qui est le propriétaire du groupe.

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

  • ACCESS_WIFI_STATE
  • CHANGE_WIFI_STATE
  • INTERNET (bien que votre appli ne se connecte pas techniquement à Internet, la communication avec des pairs Wi-Fi P2P via des sockets Java standards nécessite une connexion Internet. l'autorisation).

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

Pour en savoir plus, consultez la documentation WifiP2pManager. Aussi consultez Démo Wi-Fi P2P exemple d'application.

Appareils Bluetooth Health

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

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

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

  • BluetoothHealthCallback: vous devez étendre cette classe et implémenter la classe de rappel pour recevoir des informations sur les modifications apportées à l'état d'enregistrement de l'application et État du canal Bluetooth.
  • BluetoothHealthAppConfiguration: lors des rappels à votre BluetoothHealthCallback, vous recevez 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, comme lancer et arrêter des connexions avec les API BluetoothHealth.

Pour en savoir plus sur l'utilisation du profil d'état Bluetooth, consultez la documentation concernant BluetoothHealth.

Accessibilité

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

Mode Exploration au toucher

Les utilisateurs souffrant d'une perte de vision peuvent désormais explorer l'écran en faisant glisser un doigt sur l'écran pour entendre les descriptions vocales du contenu. Étant donné que le mode d'exploration par commande tactile fonctionne comme un curseur virtuel, il permet aux lecteurs d'écran d'identifier le texte descriptif de la même manière que lorsqu'ils naviguent 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é. Considérez donc ceci comme un rappel que vous devez fournir un texte descriptif pour les vues de votre application, en particulier pour ImageButton, EditText, ImageView et d'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 pour les versions précédentes 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 survol se produit, la vue correspondante est avertie par un appel à sendAccessibilityEvent(). Auparavant, les l'implémentation de sendAccessibilityEvent() initialisez un AccessibilityEvent et envoyez-le à AccessibilityManager. Le nouveau comportement implique des rappels supplémentaires permettant à 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() sont différées vers onInitializeAccessibilityEvent().

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

  2. Une fois initialisé, si l'événement fait partie de plusieurs types qui doivent être renseignés avec des informations textuelles, la vue reçoit ensuite un appel à dispatchPopulateAccessibilityEvent(), qui diffère du 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 à l'AccessibilityEvent, appelez getText().add().

  3. À ce stade, View transmet l'événement à la hiérarchie des vues en appelant requestSendAccessibilityEvent() le vue parent. Chaque vue parent a ensuite la possibilité d'enrichir les informations sur l'accessibilité en ajoutant un AccessibilityRecord, jusqu'à ce qu'il atteint finalement la vue racine, qui envoie l'événement à AccessibilityManager avec sendAccessibilityEvent().

En plus des nouvelles méthodes ci-dessus, qui sont utiles lorsque vous étendez 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 à la vue pour le comportement par défaut. Vous pouvez ainsi ne remplacer que les méthodes nécessaires à une vue donnée sans étendre la classe View.

Si vous souhaitez conserver la compatibilité avec les versions d'Android antérieures à la version 4.0, tout en prenant en charge les nouvelles API d'accessibilité, vous pouvez le faire avec la dernière version de la bibliothèque d'assistance v4 (dans le package de compatibilité, 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 recevoir des commentaires d'accessibilité plus avancés. Dans En particulier, les événements sont générés en fonction de la composition de la vue. Ils fournissent ainsi de meilleures informations contextuelles permettant aux services d'accessibilité de parcourir les hiérarchies de vues pour obtenir des informations supplémentaires sur les vues et traiter de cas particuliers.

Si vous développez un service d'accessibilité (un lecteur d'écran, par exemple), vous pouvez accéder des informations supplémentaires sur le contenu et parcourir les hiérarchies de vues en procédant comme suit:

  1. Lorsque vous recevez un AccessibilityEvent à partir d'une application, appelez AccessibilityEvent.getRecord() pour récupérer un AccessibilityRecord spécifique (il peut y avoir plusieurs enregistrements 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 seul nœud du contenu de la fenêtre dans un format qui vous permet d'interroger les informations d'accessibilité concernant d'un 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 à ce sujet, appelez getParent() ou getChild() pour balayer la vue et même ajouter des vues enfants au nœud.

Pour que votre application puisse s'autopublier dans 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 service d'accessibilité, consultez AccessibilityService et SERVICE_META_DATA pour en savoir plus sur la configuration XML.

Autres API d'accessibilité

Si l'état d'accessibilité de l'appareil vous intéresse, AccessibilityManager dispose de nouvelles API, telles que:

Services de correcteur orthographique

Un nouveau framework de correcteur orthographique permet aux applications de créer des correcteurs orthographiques de manière similaire au framework de méthode de saisie (pour les IME). Pour créer un correcteur orthographique, vous devez implémenter un service qui étend SpellCheckerService et étendre la classe SpellCheckerService.Session pour fournir des suggestions d'orthographe en fonction du 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 avec un service de correcteur orthographique doivent déclarer l'autorisation BIND_TEXT_SERVICE, comme l'exige le service. Le service doit également déclarer un filtre d'intent avec <action android:name="android.service.textservice.SpellCheckerService" /> comme action d'intent et doit Incluez un élément <meta-data> qui déclare les informations de configuration pour l'orthographe vérificateur.

Voir l'exemple l'application de correcteur orthographique exemple de l'application cliente de correcteur orthographique.

Moteurs de synthèse vocale

Les API de synthèse vocale (TTS) d'Android ont été considérablement étendues pour permettre aux applications d'implémenter plus facilement des moteurs TTS personnalisés, tandis que les applications qui souhaitent utiliser un moteur TTS 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 à l'aide de setEngineByPackageName(). Dans Android 4.0, la méthode setEngineByPackageName() a été abandonnée. Vous pouvez désormais spécifier le moteur à utiliser avec un nouveau constructeur TextToSpeech qui accepte le nom de package d'un moteur TTS.

Vous pouvez également interroger les moteurs de synthèse vocale disponibles avec 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.

Créer des moteurs de synthèse vocale

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

La configuration de base nécessite une implémentation de TextToSpeechService qui répond à l'intent INTENT_ACTION_TTS_SERVICE. La la tâche principale d'un moteur de synthèse vocale a lieu pendant le 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, la vitesse de parole et la hauteur de la voix.
  • SynthesisCallback : interface par laquelle votre moteur TTS fournit les données vocales résultantes en streaming audio. Le moteur doit d'abord appeler start() pour indiquer qu'il est prêt à diffuser l'audio, puis appelez 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 TTS, la prise en charge de l'implémentation du code natif a été supprimée. Rechercher 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 cadre.

Pour obtenir un exemple de moteur de synthèse vocale utilisant les nouvelles API, consultez l'application exemple Text To Speech Engine (Moteur de synthèse vocale).

Utilisation du réseau

Android 4.0 offre aux utilisateurs une visibilité précise sur la quantité de données réseau utilisée par leurs applications. L'application Paramètres fournit des commandes qui permettent aux utilisateurs de gérer les limites définies pour l'utilisation des données réseau et même désactiver l'utilisation des données en arrière-plan pour des applications individuelles. Pour éviter que les utilisateurs ne désactivent votre l'accès de votre application aux données en arrière-plan, vous devez développer des stratégies pour utiliser ces données efficacement et 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 de synchronisation des données, s'il faut effectuer des importations ou des téléchargements uniquement lorsque vous êtes connecté à un réseau Wi-Fi, s'il faut utiliser les données en itinérance, etc. Grâce à ces commandes, les utilisateurs sont bien moins susceptibles de désactiver l'accès de votre application aux données lorsqu'elles atteignent leurs limites, car ils peuvent contrôler avec précision la quantité de données utilisée par votre application. Si vous fournissez une activité de préférence avec ces paramètres, vous devez l'inclure dans son fichier manifeste un filtre d'intent pour ACTION_MANAGE_NETWORK_USAGE action. 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 votre la consommation des données de votre application. Ainsi, lorsque l'utilisateur inspecte la quantité de données que votre application utilise l'application Paramètres, une option qui permet d'afficher les paramètres de l'application est disponible pour lancer votre préférences afin que l'utilisateur puisse affiner la quantité de données utilisées par votre application.

Notez également que getBackgroundDataSetting() est désormais obsolète et renvoie toujours "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 est connecté. Vous pouvez ensuite vérifier d'autres propriétés de connexion, telles que si l'appareil est en itinérance ou connectés au Wi-Fi.

Entreprise

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

Services VPN

La nouvelle 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 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, il y a des implications en termes de sécurité. Par conséquent, si vous implémentez VpnService, votre service doit exiger BIND_VPN_SERVICE pour s'assurer que seul le système peut s'y lier (seule cette autorisation est accordée au système, les applications ne peuvent pas la demander). Pour utiliser 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 de l'appareil 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 de la stratégie).

Gestion des certificats

La nouvelle classe KeyChain fournit des API qui vous permettent d'importer et d'accéder aux certificats dans le magasin de clés système. Les certificats simplifient l'installation des certificats client (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 auprès des serveurs. Pour en savoir plus, consultez la documentation KeyChain.

Capteurs de l'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 (de la pièce) en degrés Celsius.
  • TYPE_RELATIVE_HUMIDITY: capteur d'humidité qui fournit le humidité relative ambiante (room), exprimée en pourcentage.

Si un appareil dispose à 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 précédent capteur de température, TYPE_TEMPERATURE, a été abandonné. Vous devez plutôt utiliser le capteur TYPE_AMBIENT_TEMPERATURE.

De plus, les trois capteurs synthétiques d'Android ont été considérablement améliorés afin de réduire la latence et 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 de 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 élégante la taille et la configuration de la barre d'action lorsqu'il 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, lorsque le téléphone est en mode portrait), les onglets de navigation de la barre d'action s'affichent dans une "barre empilée", qui s'affiche directement sous la barre d'action principale. Vous pouvez activer l'option "Diviser la barre d'action", qui place tous les éléments d'action dans une barre distincte en bas lorsque celui-ci est étroit.

Diviser la barre d'action

Si votre barre d'action inclut plusieurs éléments d'action, ils ne tiendront pas tous dans la barre d'action sur un écran étroit. Le système en placera donc davantage dans le menu à développer. Toutefois, Android 4.0 vous permet d'activer la "barre d'action fractionnée" afin que davantage d'éléments d'action puissent apparaître à l'écran dans une barre distincte en bas de l'écran. Pour activer la barre d'action de fractionnement, ajoutez android:uiOptions avec "splitActionBarWhenNarrow" à votre <application> ou tags <activity> individuels dans votre fichier manifeste. Lorsque cette option est activée, le système ajoute une barre supplémentaire en bas pour afficher toutes les tâches lorsque l'écran est étroit (aucune tâche n'apparaît barre d'action).

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 ne souhaitez que les onglets apparaissent en haut), activez la barre d'action fractionnée comme décrit ci-dessus et appelez également setDisplayShowHomeEnabled(false) pour désactiver l'icône de l'application dans la barre d'action. La barre d'action principale étant vide, Il ne reste plus que les onglets de navigation en haut de l'écran et les tâches en bas de l'écran.

Styles de 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 arrière-plan. d'un drawable ou d'une couleur à la barre empilée et à la barre de division, respectivement. Vous pouvez également définir ces styles sur avec setStackedBackgroundDrawable() et setSplitBackgroundDrawable().

Fournisseur d'actions

La nouvelle classe ActionProvider vous permet de créer un gestionnaire spécialisé pour les éléments d'action. 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 une action à effectuer comportements dynamiques (tels qu'une vue d'action variable, une action par défaut ou un sous-menu), étendre ActionProvider est une bonne solution pour créer un composant réutilisable, plutôt que gérer les différentes transformations d'éléments d'action dans votre fragment ou votre activité.

Par exemple, ShareActionProvider est une extension de ActionProvider qui facilite le "partage" dans la barre d'action. Au lieu d'utiliser une tâche traditionnelle qui appelle l'intent ACTION_SEND, vous pouvez utilisez 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 fournit dans la vue d'action pour un accès plus rapide au partage avec cette application.

Pour déclarer un fournisseur d'actions pour un élément d'action, 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. Exemple :

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

Dans les onCreateOptionsMenu() de votre activité de rappel, récupérez une instance du fournisseur d'actions à partir de l'élément de menu et définissez 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'actions réductibles

Les tâches qui fournissent une vue d'action peuvent désormais basculer entre leur état de vue d'action et l'état classique de la tâche. Auparavant, seul SearchView était compatible avec le repliage lorsqu'il était utilisé comme vue d'action. Désormais, vous pouvez ajouter une vue d'action pour n'importe quel élément d'action et basculer entre l'état développé (la vue d'action 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 la vue développée à 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 le faire lors du rappel onCreateOptionsMenu().

Pour contrôler une vue réductible des actions, vous pouvez appeler collapseActionView() et expandActionView() sur le 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éduit.

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 "en haut" (transmettez "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 désactiver la visibilité des éléments du menu d'options déclarés par le fragment. Cette fonctionnalité est utile si fragment a été ajouté à l'activité, mais n'est pas visible. Les éléments du menu doivent donc être masquées.
  • FragmentManager.invalidateOptionsMenu() vous permet d'invalider le menu d'options de l'activité pendant différents états du cycle de vie du fragment qui peut ne pas être disponible avec la méthode équivalente de Activity.

Interface utilisateur et vues

Android 4.0 introduit plusieurs 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 s'appuie sur une hiérarchie plate et n'utilise pas de vues intermédiaires telles que les lignes de tableau pour fournir une structure. À la place, les enfants spécifient la ou les lignes et les colonnes qu'ils doivent occuper (les cellules peuvent s'étendre sur plusieurs lignes et/ou colonnes), et sont disposées par défaut de manière séquentielle dans les lignes et les colonnes de la grille. L'orientation GridLayout détermine si les enfants séquentiels sont par défaut disposés horizontalement ou verticalement. L'espace entre les enfants peut être spécifié en utilisant instances de la nouvelle vue Space ou en définissant les paramètres de marge appropriés sur les enfants.

Consultez ApiDemos. pour obtenir des exemples avec GridLayout.

TextureView

TextureView est une nouvelle vue qui vous permet d'afficher un flux de contenu, tel que comme une vidéo ou une scène OpenGL. Bien que semblable à SurfaceView, TextureView se comporte comme une vue standard au lieu de créer une une fenêtre distincte. Vous pouvez donc la 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().

Sachez que TextureView ne fonctionne que dans une fenêtre accélérée par le matériel.

Pour en savoir plus, consultez la documentation TextureView.

Widget de commutateur

Le nouveau widget Switch est un bouton d'activation/de désactivation à deux états que les utilisateurs peuvent faire glisser vers un seul. sur le côté ou l'autre (ou simplement en appuyant dessus) pour passer d'un état à un autre.

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

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

Android 3.0 a introduit PopupMenu pour créer de courts menus contextuels 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 la 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 pour qui fournissent 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

Thème par défaut pour toutes les applications ciblant Android 4.0 (en définissant targetSdkVersion ou minSdkVersion jusqu'à “14" ou supérieure) est désormais la "appareil par défaut" thème: Theme.DeviceDefault. Il peut s'agir le thème Holo sombre ou un autre thème sombre défini par l'appareil spécifique.

Les thèmes de la famille Theme.Holo ne seront pas modifiés. d'un appareil à un autre lorsqu'ils exécutent la même version d'Android. Si vous avez explicitement appliquer l'un des Theme.Holo thèmes à vos activités, vous pouvez soyez assuré que ces thèmes ne changeront pas de caractère sur différents appareils au sein d'une même de la plate-forme.

Si vous souhaitez que votre application s'intègre au thème général de l'appareil (par exemple, lorsque différents OEM propose des thèmes par défaut différents 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 n'ont plus besoin d'un bouton physique "Menu". Toutefois, vous n'avez pas à vous en préoccuper si votre application existante fournit un menu d'options et s'attend à ce qu'il y ait un bouton de menu. Pour s'assurer que les applications existantes continuent de fonctionner comme prévu, le système fournit une pour les applications conçues pour d'anciennes versions d'Android.

Pour une expérience utilisateur optimale, les applications nouvelles et mises à jour doivent utiliser ActionBar pour permettre l'accès aux éléments de menu et définir targetSdkVersion sur "14" pour exploiter les derniers comportements par défaut du framework.

Commandes de visibilité de l'UI du système

Depuis les débuts d'Android, le système gère un composant d'UI appelé status située en haut des téléphones pour fournir des informations telles que le nom de l'opérateur le signal, l'heure, les notifications, etc. Android 3.0 a ajouté la barre système pour les tablettes appareils, qui se trouve en bas de l'écran pour fournir les commandes de navigation du système (Accueil, "Retour" et ainsi de suite), ainsi qu'une interface pour les éléments traditionnellement fournis par la barre d'état. Dans Android 4.0, le système fournit un nouveau type d'UI du système appelé barre de navigation. Vous pouvez considérer la barre de navigation comme une version retravaillée de la barre système conçue pour les téléphones. Elle fournit des commandes de navigation pour les appareils qui ne disposent pas de contreparties matérielles pour naviguer dans le système, mais elle ne comprend pas l'UI de notification et les commandes de paramétrage de la barre système. Par conséquent, un appareil qui fournit la barre de navigation comporte également la barre d'état en haut.

À ce jour, vous pouvez masquer la barre d'état sur les 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'indicateur SYSTEM_UI_FLAG_LOW_PROFILE remplace l'indicateur STATUS_BAR_HIDDEN. Lorsqu'il est défini, cet indicateur active le mode "profil bas" pour la barre système ou la barre de navigation. Les boutons de navigation s'assombrissent et les autres éléments de la barre système sont également masqués. Cette option est utile pour créer des jeux plus immersifs sans distraction pour les boutons de navigation du système.
  • L'indicateur SYSTEM_UI_FLAG_VISIBLE remplace l'indicateur STATUS_BAR_VISIBLE pour demander que la barre système ou la barre de navigation soit visible.
  • SYSTEM_UI_FLAG_HIDE_NAVIGATION est un nouveau flag qui demande à la barre de navigation de se masquer complètement. Notez que cette méthode 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 navigation la barre s'affiche dès que le système reçoit une entrée utilisateur. Par conséquent, ce mode est principalement utile pour la lecture vidéo ou d'autres cas où l'intégralité de l'écran est nécessaire, mais où l'entrée utilisateur n'est pas 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 (OR) tous les indicateurs de toutes les vues de votre fenêtre et les applique à l'UI du système tant que votre fenêtre est sélectionnée. Lorsque votre fenêtre perd des données (l'utilisateur quitte votre application ou une boîte de dialogue s'affiche), vos signalements 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é avec les modifications de visibilité de l'UI du système (par par exemple, masquer la barre d'action ou d'autres commandes d'interface utilisateur lorsque l'interface utilisateur du système est masquée), vous devez enregistrer un View.OnSystemUiVisibilityChangeListener pour recevoir une notification lorsque de la barre système ou de la barre de navigation change.

Consultez les OverscanActivity pour une démonstration des différentes options de l'UI du système.

Framework d'entrée

Android 4.0 prend en charge les événements de survol du curseur, ainsi que de nouveaux événements de bouton de souris et de stylet.

Événements de pointage

La classe View prend désormais en charge les événements de survol pour permettre des interactions plus riches à l'aide de dispositifs de pointage (comme une souris ou d'autres dispositifs qui pilotent un curseur à l'écran).

Pour recevoir des événements de pointage sur une vue, implémentez View.OnHoverListener et l'enregistrer auprès de setOnHoverListener(). Lorsqu'un événement de survol se produit sur la vue, votre écouteur reçoit un appel à onHover(), fournissant le View qui a reçu l'événement et un MotionEvent qui décrit le type d'événement de survol qui s'est produit. L'événement de survol peut ê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 L'écouteur renvoie la valeur "false", l'événement de survol est alors envoyé à la vue parent, comme d'habitude.

Si votre application utilise des boutons ou d'autres widgets qui changent d'apparence 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 drawable de fond différent lorsqu'un curseur se trouve au-dessus de la vue.

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

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

Android fournit désormais des API pour recevoir les entrées d'un stylet, comme une tablette avec numériseur ou un écran tactile compatible avec le stylet.

La saisie au stylet fonctionne de la même manière que la saisie tactile ou avec la souris. Lorsque le stylet est en contact avec le numériseur, les applications reçoivent les événements tactiles de la même manière qu'avec le doigt appuyez sur l'écran. Lorsque le stylet est au-dessus du numériseur, les applications reçoivent des événements de survol, comme si un pointeur de souris était déplacé sur l'écran sans appuyer sur aucun bouton.

Votre application peut faire la distinction entre les entrées avec le doigt, la souris, le stylet et la gomme en interrogeant le "type d'outil" associé à chaque pointeur dans un MotionEvent à l'aide de getToolType(). Les types d'outils actuellement définis sont les suivants : TOOL_TYPE_UNKNOWN, TOOL_TYPE_FINGER, TOOL_TYPE_MOUSE, TOOL_TYPE_STYLUS et TOOL_TYPE_ERASER. En interrogeant le type d'outil, votre application peuvent choisir de gérer la saisie au stylet différemment de la saisie au doigt ou à la souris.

Votre application peut également interroger les boutons de la souris ou du stylet enfoncés en interrogeant l'état des boutons d'un MotionEvent à l'aide de getButtonState(). Les états de 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 prendre en charge la navigation avant et arrière basée sur les boutons de la souris.

En plus de mesurer avec précision la position et la pression d'un contact, certaines saisies au stylet les appareils signalent également la distance entre l'extrémité du stylet et le numérique, 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 obtenir une démonstration des types d'outils, des états des boutons et des nouveaux codes des axes, reportez-vous au module TouchPaint dans ApiDemos.

Propriétés

La nouvelle classe Property offre un moyen rapide, efficace et facile de spécifier un sur tout objet permettant aux appelants de définir/obtenir de manière générique des valeurs sur les objets cibles. Il permet également de transmettre des références de champ/méthode et de définir/obtenir les 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, vous deviez auparavant procédez comme suit:

Kotlin

foo.setBar(value)

Java

foo.setBar(value);

Toutefois, si vous souhaitez transmettre l'instance foo et que vous souhaitez que d'autres codes définissent la valeur bar, il n'existe 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 pouvoir 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 permettent 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 un ObjectAnimator avec un Property, ce qui est plus rapide, plus efficace et plus sûr que l'approche basée sur les 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 valeur supérieure. L'accélération matérielle entraîne généralement des animations et un défilement plus fluides, ainsi que de meilleures performances et une meilleure réponse aux interactions utilisateur.

Si nécessaire, vous pouvez désactiver manuellement l'accélération matérielle à l'aide de la commande hardwareAccelerated pour des éléments <activity> individuels ou le <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 la liste des dessins non compatibles consultez la page Gestion des appareils d'accélération.

Modifications JNI

Dans les versions précédentes d'Android, les références locales JNI n'étaient pas des poignées indirectes. Android utilisait des pointeurs directs. Ce n'était pas un problème tant que le récupérateur de mémoire n'avait pas déplacé les objets, semblait fonctionner parce qu'il permettait d'écrire du code avec des bugs. Dans Android 4.0, le système utilise désormais des références indirectes pour détecter ces bugs.

Les tenants et les aboutissants des références locales JNI sont décrits dans "Références locales et globales" dans les conseils JNI. Sur Android 4.0, CheckJNI a été amélioré pour détecter ces erreurs. Consultez le blog des développeurs Android pour connaître les prochaines publications. sur les erreurs courantes avec les références JNI et sur la façon de les corriger.

Ce changement dans l'implémentation JNI ne concerne 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, alors les références locales JNI se comportent de la même manière que dans les versions précédentes.

WebKit

  • Mise à jour de WebKit vers la version 534.30
  • Prise en charge des polices indiennes (dévanagari, bengali et tamoul, y compris la prise en charge des caractères complexes requise pour combiner des glyphes) dans WebView et le navigateur intégré
  • Compatibilité des polices éthiopienne, géorgienne et arménienne dans WebView et dans les navigateur intégré
  • La compatibilité avec WebDriver permet vous pouvez tester plus facilement les applications qui utilisent WebView

Navigateur Android

L'application 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 des appareils:

  • FEATURE_WIFI_DIRECT: déclare que l'application utilise Wi-Fi pour les communications peer-to-peer.

Pour obtenir un aperçu détaillé de toutes les modifications apportées aux 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. La plate-forme Android 3.x n'étant disponible que pour les appareils à grand écran, si vous avez développé principalement pour les téléphones, 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 désormais disponibles sur les téléphones portables:

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 UI et leur propre cycle de vie. Consultez le guide du développeur sur les fragments.
  • ActionBar: remplace la barre de titre traditionnelle en haut de la fenêtre d'activité. Elle inclut le logo de l'application dans le coin gauche et fournit une nouvelle pour accéder aux éléments de menu. Consultez le Barre d'action du guide du développeur.
  • Loader : composant de framework qui facilite le chargement asynchrone de données en combinaison avec des composants d'interface utilisateur pour charger dynamiquement des données sans bloquer le thread principal. Consultez le guide du développeur sur les chargeurs.
  • Presse-papiers du système: les applications peuvent copier et coller des données (au-delà du texte) vers et depuis le presse-papiers du système. Les données coupées peuvent être du texte brut, un URI ou un intent. Consultez le guide du développeur sur la Copie et le collage.
  • Glisser-déposer: ensemble d'API intégrées au framework des vues qui facilite le glisser-déposer opérations. Consultez le guide du développeur sur le glisser-déposer.
  • Un tout nouveau framework d'animation flexible vous permet d'animer les propriétés arbitraires (View, Drawable, Fragment, Object ou autre) et définissez les aspects de l'animation tels que comme la durée, l'interpolation, la répétition et plus encore. Le nouveau framework rend les animations dans Android plus simple que jamais. Consultez le Développeur d'animations de propriétés .
  • Graphismes RenderScript et Compute Engine: RenderScript propose un rendu 3D hautes performances le rendu graphique et l'API de calcul au niveau natif, que vous écrivez en C (norme C99), Il offre les performances attendues d'un environnement natif, tout en restant sur divers processeurs et GPU. Consultez le Développeur RenderScript .
  • Graphismes 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 fichier manifeste ou pour des <activity> spécifiques éléments. Cela se traduit par des animations et un défilement plus fluides, ainsi que par de meilleures performances et une meilleure réponse aux interactions utilisateur.

    Remarque:Si vous définissez le paramètre minSdkVersion ou targetSdkVersion de votre application sur "14" ou version ultérieure, l'accélération matérielle est activée par défaut.

  • et bien plus encore. Consultez la page sur la plate-forme Android 3.0. pour en savoir plus.
Android 3.1
  • API USB: de nouvelles API puissantes pour intégrer des périphériques connectés à applications Android. Ces API reposent sur une pile USB et sur des services intégrés à la plateforme, notamment la prise en charge des interactions entre les hôtes et appareils USB. Consultez le guide du développeur sur les hôtes et accessoires USB.
  • API MTP/PTP: les applications peuvent interagir directement avec les caméras connectées et d'autres appareils pour recevoir des notifications lorsque des appareils sont connectés et retirés, gérer les fichiers et l'espace de stockage sur ces appareils, et transférer des fichiers et des métadonnées vers et depuis ces appareils. L'API MTP implémente le sous-ensemble PTP (Picture Transfer Protocol) de la spécification MTP (Media Transfer Protocol). Consultez la documentation sur 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 des flux de données interactifs ou à la demande. En particulier, les applications qui fournissent des appels VoIP, Push-to-Talk, des conférences et des flux audio peuvent utiliser l'API pour lancer des sessions et transmettent ou reçoivent des flux de données sur n’importe quel réseau disponible. Consultez la documentation sur android.net.rtp.
  • Prise en charge des joysticks et d'autres entrées de mouvement génériques.
  • Consultez les notes sur la plate-forme Android 3.1 pour découvrir de nombreuses autres nouvelles API.
Android 3.2
  • Les nouveaux écrans sont compatibles avec 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 de compatibilité d'écran existant avec la possibilité de cibler précisément des plages de tailles d'écran spécifiques par dimensions, mesurées en unités de pixels indépendants de la densité (par exemple, 600 dp ou 720 dp de large), plutôt que par leurs tailles d'écran généralisées (par exemple, "large" ou "très grand"). C'est important, par exemple, pour vous aider faites la distinction entre un un appareil mobile de 7 pouces appareil, qui sont traditionnellement regroupés dans des ensembles "large" écrans. Lire l'article de blog, Nouveaux outils pour gérer les tailles d'écran.
  • Nouvelles constantes pour <uses-feature> déclarer les exigences concernant l'orientation d'écran en mode paysage ou portrait ;
  • La "taille de l'écran" de l'appareil modification de la configuration lors de l'orientation de l'écran le changement. Si votre application cible le niveau d'API 13 ou une version ultérieure, vous devez gérer la modification de configuration "screenSize" si vous souhaitez également gérer la modification de configuration "orientation". Voir android:configChanges pour en savoir plus.
  • Pour en savoir plus sur les autres nouvelles API, consultez les notes sur la plate-forme Android 3.2.

Niveau d'API

L'API Android 4.0 se voit attribuer un identifiant entier (14) stocké dans le système lui-mê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 avec une plate-forme Android compatible avec le niveau d'API 14 ou version ultérieure. Selon vos besoins, vous devrez peut-être ajouter un l'attribut android:minSdkVersion="14" à <uses-sdk> .

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