API Android 4.0

Niveau d'API:14

Android 4.0 (ICE_CREAM_SANDWICH) est une version majeure de la plate-forme qui ajoute diverses nouvelles fonctionnalités pour les utilisateurs et les applications développeurs. Outre toutes les nouvelles fonctionnalités et API décrites ci-dessous, Android 4.0 est une fonctionnalité importante de la plate-forme, car elle intègre le vaste ensemble d'API et de thèmes holographiques 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 permet de développer et de publier votre application avec un seul fichier APK expérience utilisateur optimisée pour les téléphones, les tablettes, etc., lorsqu'ils utilisent la même version de 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 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 sur 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 fournissent un aperçu technique des nouvelles API dans Android 4.0.

API de réseau social dans Contacts Provider

Les API de contact définies par le fournisseur ContactsContract ont été étendu pour prendre en charge de nouvelles fonctionnalités orientées vers 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 à rejoindre les réseaux sociaux installés sur le 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. Applications de réseau social qui gèrent l'identité des utilisateurs peut contribuer aux données de profil de l'utilisateur en créant une entrée ContactsContract.RawContacts dans ContactsContract.Profile. c'est-à-dire les contacts bruts qui représentent l'utilisateur de l'appareil n'appartiennent pas à la table des contacts bruts traditionnelle définie par l'URI ContactsContract.RawContacts ; vous devez ajouter un contact brut du profil au 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 les données du profil, table, vous devez demander l'autorisation android.Manifest.permission#READ_PROFILE. Toutefois, la plupart des applications n'ont pas besoin de lire le profil utilisateur, même lorsqu'elles contribuent aux données profil. La lecture du profil utilisateur est une autorisation sensible et vous devez vous attendre à ce que les utilisateurs soient sceptique à l'égard des applications qui le demandent.

Intent d'invitation

L'action d'intent INVITE_CONTACT autorise une application pour invoquer une action qui indique 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é à sur le réseau social. La plupart des applications seront côté 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 répertorié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 l'application répond à l'intent INVITE_CONTACT en en ajoutant l'attribut inviteContactActivity au fichier de configuration de synchronisation de votre application, avec une 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 alors récupérer l'URI du contact en question à partir de l'intent données et effectuer le travail nécessaire pour inviter ce contact au réseau ou l'ajouter au réseau les connexions de l'utilisateur.

Photos volumineuses

Android prend désormais en charge les photos haute résolution pour les contacts. Désormais, lorsque vous ajoutez une photo de contact, le système le traite à la fois en une vignette de 96 x 96 (comme c'était le cas auparavant) et en "afficher une photo" au format 256 x 256 stocké dans un nouveau magasin de photos basé sur des fichiers (les dimensions exactes choisi par le système peut 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, Les adaptateurs de synchronisation qui synchronisent l'agenda d'un utilisateur d'autres services d'agenda avec le fournisseur d'agenda, afin de proposer un emplacement unique pour tous les événements de l'utilisateur. Par exemple, les événements Google Agenda sont synchronisés avec le fournisseur d'agenda l'adaptateur de synchronisation Google Agenda, ce qui permet d'afficher ces événements avec l'outil intégré d'Android Agenda.

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 attributs des informations. 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 aux événements. 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 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 les heures de début et de fin de les occurrences d'un événement. Chaque ligne de ce tableau représente une seule occurrence. Pour les événements ponctuels il y a un mappage « un à un » 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 sa réponse à 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é 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 que vous puissiez 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) ; WRITE_CALENDAR (pour l'accès en écriture) ;

Intention de l'é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 au 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. La 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 capable de lire tous les messages vocaux, Chaque application fournissant 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 pas les applications tierces à lire tous les messages vocaux du les seules applications tierces à utiliser les API de messagerie vocale sont celles à livrer à 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. La le système effectue tous les traitements d'effets sur le GPU pour obtenir des performances optimales.

Pour des performances optimales, les effets sont appliqués directement aux textures OpenGL. Votre application Il doit disposer d'un contexte OpenGL valide pour 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 auquel vous pouvez l'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.

Pour ajuster les paramètres d'un effet, appelez setParameter(), et transmettez un nom et une valeur de paramètre. Chaque type d'effet accepte différents paramètres, qui sont indiqués avec le nom de l'effet. Par exemple, EFFECT_FISHEYE comporte un paramètre pour le scale du ces distorsions.

Pour appliquer un effet à une texture, appelez apply() au niveau de la Effect et transmettre la texture d'entrée, sa largeur et sa hauteur, ainsi que la sortie ou la texture. La texture d'entrée doit être liée à une texture GL_TEXTURE_2D image (généralement effectuée en appelant la méthode glTexImage2D() ). Vous pouvez fournir plusieurs niveaux de mipmaps. Si la texture de sortie n'a pas été liée à une de texture, elle sera automatiquement liée à l'effet en tant que GL_TEXTURE_2D et avec un niveau de mipmaps (0), qui aura le même comme 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é depuis la bibliothèque externe est pris en charge en appelant isEffectSupported()

Client de contrôle à distance

Le nouveau RemoteControlClient permet aux lecteurs multimédias d'activer la lecture des commandes des clients de télécommande à distance, 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 qui s'affiche sur la télécommande, comme le morceau de musique des informations et des pochettes d'albums.

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 commandes multimédias que le 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 recevra ACTION_MEDIA_BUTTON événements lorsqu'un utilisateur appuie sur un bouton depuis une télécommande. L'intent que vous recevez inclut le KeyEvent pour la touche multimédia sur laquelle vous appuyez, que vous pouvez récupérer à partir de l'intent avec getParcelableExtra(Intent.EXTRA_KEY_EVENT).

Pour afficher des informations sur la télécommande concernant le contenu multimédia en cours de lecture, appelez editMetaData() et ajoutez des métadonnées au RemoteControlClient.MetadataEditor Vous pouvez fournir un bitmap pour les illustrations multimédias, Des informations numériques (comme le temps écoulé) et des informations textuelles (le titre du morceau, par exemple). Pour des informations 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 équipés d'Android 2.1.

Lecteur multimédia

  • La diffusion de contenus multimédias en ligne à partir de MediaPlayer nécessite désormais l'autorisation INTERNET. Si vous utilisez MediaPlayer pour lire du contenu sur Internet, veillez à ajouter le INTERNET autorisation d'accéder à votre fichier manifeste, sinon la lecture des contenus multimédias ne fonctionnera pas à partir d'Android 4.0.
  • setSurface() vous permet de définir un Surface qui se comportera en tant que récepteur 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:

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

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

Appareil photo

La classe Camera inclut désormais des API de détection des visages et de contrôle 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:

  • Élément Rect spécifiant les limites du visage par rapport à la champ de vision actuel
  • Entier compris entre 1 et 100 qui indique le degré de confiance du système quant au fait que l'objet est visage humain
  • Un identifiant unique vous permettant de suivre plusieurs visages
  • Plusieurs objets Point indiquant la position des yeux et de la bouche localisé

Remarque:La détection des visages peut ne pas être disponible sur certains appareils. appareils. Vous devez donc vérifier en appelant getMaxNumDetectedFaces() et vous assurer que le retour 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, les 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 son épaisseur, qui représentent le niveau d'importance de ces par rapport aux autres zones prises en compte, par un nombre 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 elles renvoient zéro, alors l'appareil ne prend pas en charge la fonctionnalité correspondante.

Pour spécifier les zones de mise au point ou de mesure à utiliser, il suffit d'appeler setFocusAreas() ou setMeteringAreas(). Elles prennent chacune 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 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 réactiver CAF après avoir reçu le rappel, vous devez appeler cancelAutoFocus().

Remarque:L'autofocus en continu est également disponible lors de l'enregistrement. à l'aide de FOCUS_MODE_CONTINUOUS_VIDEO, (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 éviter ces propriétés de changer.
  • Vous pouvez maintenant appeler setDisplayOrientation() lorsque l'aperçu de la caméra est en cours d'exécution. Auparavant, vous pouviez appeler cette méthode avant de lancer l'aperçu, mais vous pouvez 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'appli Appareil photo intégrée appelle diffuser 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: Ce libellé indique que l'utilisateur a enregistré une nouvelle vidéo. L'appli Appareil photo intégrée appelle diffuser 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 (NDEF Push avec NFC)

Android Beam est une nouvelle fonctionnalité NFC qui vous permet d'envoyer des messages NDEF depuis un appareil vers un autre (processus également connu sous le nom de « push NDEF »). 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 contenues dans le message NDEF peuvent contenir toutes les données que vous souhaitez partager entre les appareils. Par exemple, l'application Contacts permet de partager 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 active. au premier plan. Vous devez ensuite transmettre NdefMessage au système via l'une différentes manières:

  • Définissez un seul élément NdefMessage à transmettre dans 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 alors que l'activité est dans la 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 laquelle votre l'implémentation de 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 le NdefMessage pour qu'il ne soit diffusé qu'une fois qu'Android Beam est lancé, au cas où le contenu du message peut varier tout au long de la durée de l'activité.

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

Sur l'appareil destinataire, le système envoie les messages Push NDEF de la même manière que le NFC standard. . Le système appelle un intent avec le 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é que vous souhaitez vous pouvez déclarer des filtres d'intent pour les URL ou les types MIME importants pour votre application. Pour plus plus d'informations sur Tag Dispatch, 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 format spécial que votre application doit recevoir lors d'un événement Android Beam, vous devez créer un filtre d'intent pour votre activité en utilisant le même schéma d'URI afin de recevoir les message NDEF entrant.

Vous devez également transmettre un "enregistrement d'application Android" avec votre NdefMessage dans pour garantir que votre application gère le message NDEF entrant, même si d'autres les 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 le un enregistrement d'application et 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 la correspondance l'enregistrement d'application). 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 l'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 page Android Beam 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 ensemble d'API Wi-Fi P2P qui vous permettent de détecter d'autres appareils et de vous y connecter lorsque chaque appareil prend en charge le Wi-Fi P2P, puis communiquent 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 opérations peer-to-peer. connexions via le Wi-Fi. La classe principale avec laquelle vous devez travailler est WifiP2pManager. Vous pouvez l'acquérir en appelant getSystemService(WIFI_P2P_SERVICE). Le WifiP2pManager inclut des API qui vous permettent:

  • 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 à ceux-ci réussit ou échoue.
  • L'interface WifiP2pManager.PeerListListener vous permet de recevoir des informations sur les pairs découverts. Le rappel fournit un WifiP2pDeviceList, à partir duquel vous pouvez récupérer un objet WifiP2pDevice pour chaque appareil à portée et obtenir des informations telles que : le nom, 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 le nom du réseau et la phrase secrète.
  • 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 Wi-Fi P2P:

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

Appareils Bluetooth Health

Android prend désormais en charge les appareils de profil de santé Bluetooth, ce qui vous permet de créer des applications qui utilisent Bluetooth pour communiquer avec les appareils de santé qui prennent en charge le Bluetooth, tels que les cardiofréquencemètres, les glucomètres, les thermomètres et les 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 obtenu le proxy du profil de santé (BluetoothHealth ), la connexion et la communication avec des appareils de santé associés impliquent les nouveaux Classes Bluetooth:

  • 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. Comme le mode Exploration au toucher fonctionne comme curseur virtuel, il permet aux lecteurs d'écran d'identifier le texte descriptif de la même manière que les lecteurs peuvent lorsque l'utilisateur navigue avec un pavé directionnel ou un trackball, en lisant les informations fournies par android:contentDescription et setContentDescription() après une simulation de survol . Donc, n'oubliez pas que vous devez fournir un texte descriptif pour les vues de votre l'application, en particulier pour ImageButton, EditText, ImageView et d'autres widgets susceptibles de ne pas contenir naturellement des texte.

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 tout d'abord que le comportement de la méthode sendAccessibilityEvent() a changé dans Android. 4.0. Comme pour 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 survol se produit, la vue concernée reçoit 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 qui permettent à la vue et à ses parents d'ajouter des informations contextuelles à l'événement:

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

    Les implémentations personnalisées de View peuvent souhaiter implémenter onInitializeAccessibilityEvent() pour joindre des informations d'accessibilité supplémentaires à AccessibilityEvent, mais doit également appeler la super-implémentation pour fournissent des informations par défaut telles que la description standard du contenu, l'index des éléments, 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 des différents types qui doivent être renseignés avec du texte d'informations, la vue reçoit alors un appel à dispatchPopulateAccessibilityEvent(), qui se remet à onPopulateAccessibilityEvent() .

    Les implémentations personnalisées de View doivent généralement implémenter onPopulateAccessibilityEvent() pour ajouter des le contenu textuel à AccessibilityEvent si le texte android:contentDescription est manquant ou insuffisant. Pour ajouter un texte de description 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 au AccessibilityManager avec sendAccessibilityEvent().

En plus des nouvelles méthodes ci-dessus, qui sont utiles pour étendre 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 la même méthode dans View.AccessibilityDelegate. Toutes les méthodes non gérées par le délégué sont renvoyés directement dans la vue pour le comportement par défaut. Cela vous permet de remplacer uniquement 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é, vous pouvez le faire grâce à la dernière version de la compatibilité avec la version 4 bibliothèque (dans le package de compatibilité r4) à l'aide d'un ensemble de classes utilitaires fournissant les nouvelles API d'accessibilité dans un environnement rétrocompatible conception.

Services d'accessibilité

Si vous développez un service d'accessibilité, les informations sur les différents événements a été considérablement étendue pour permettre aux utilisateurs de bénéficier de commentaires plus avancés sur l'accessibilité. 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. Lors de la réception d'un AccessibilityEvent d'une application, appelez AccessibilityEvent.getRecord() pour récupérer un AccessibilityRecord spécifique (plusieurs enregistrements peuvent être associés au ).
  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 de Une AccessibilityRecord décrit le prédécesseur de l'événement source.

  3. Avec AccessibilityNodeInfo, vous pouvez interroger des informations à ce sujet, appelez getParent() ou getChild() pour parcourir la vue et même ajouter des vues enfants au nœud.

Pour que votre application soit publiée dans le système en tant que service d'accessibilité, 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 correcteur orthographique permet aux applications de créer des correcteurs orthographiques de la même manière que Framework de mode 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 orthographiques basées sur sur le texte fourni par les méthodes de rappel de l'interface. Dans les méthodes de rappel SpellCheckerService.Session, vous devez renvoyer le les suggestions orthographiques en tant qu'objets SuggestionsInfo.

Les applications dotées d'un service de correction 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 <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 d'Android ont été considérablement étendues pour permettre aux applications pour implémenter plus facilement des moteurs de synthèse vocale personnalisés, alors que les applications qui souhaitent utiliser un moteur de synthèse vocale ont un deux 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é obsolète et 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 avec getEngines(). Cette méthode renvoie une liste d'objets TextToSpeech.EngineInfo, qui incluent des métadonnées telles que les données l'icône, le libellé et le nom du package.

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 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 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 diffuse cette deuxième méthode 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 utilisée par le moteur de synthèse vocale fournit les données vocales résultantes sous forme de flux 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 permettant de créer des moteurs de synthèse vocale, la prise en charge 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.

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 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 qui permettent aux utilisateurs de contrôler les habitudes de données de votre application, comme la fréquence de synchronisation des données, d'importer/de télécharger des données uniquement en Wi-Fi, d'utiliser des données en itinérance, etc. les options dont ils disposent, les utilisateurs sont beaucoup moins susceptibles de désactiver l'accès de votre application aux données ils approchent de 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.

Attention non seulement à getBackgroundDataSetting() : obsolète et renvoie toujours la valeur "true". Utilisez plutôt getActiveNetworkInfo(). Avant d'essayer d'établir transactions, vous devez toujours appeler getActiveNetworkInfo() pour obtenir le NetworkInfo qui représente le réseau actuel, puis interrogez isConnected() pour vérifier si l'appareil dispose d'un . 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

Le nouveau VpnService permet aux applications de créer leur propre VPN (VPN réseau privé), s'exécutant 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 définir 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é. Ainsi, si vous implémenter VpnService, alors votre service doit exiger BIND_VPN_SERVICE pour garantir que seul le système peut s'y associer (uniquement le système obtient 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 l'appareil photo à 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 données et d'y accéder de certificats dans le magasin de clés du système. Les certificats simplifient l'installation des deux clients les certificats (pour valider l'identité de l'utilisateur) et les certificats de l'autorité de certification (pour vérifier l'identité du serveur). Des applications telles que des navigateurs Web ou des clients de messagerie peuvent accéder aux des certificats pour authentifier les utilisateurs auprès des serveurs. Voir le KeyChain pour en savoir plus.

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 est équipé à la fois des 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é obsolète. Vous devez utiliser le capteur TYPE_AMBIENT_TEMPERATURE à la place.

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 à vecteur de rotation (TYPE_ROTATION_VECTOR) et le capteur d'accélération linéaire (TYPE_LINEAR_ACCELERATION). Les capteurs améliorés reposent sur le gyroscope pour améliorer la qualité de sortie, de sorte que les capteurs n'apparaissent que sur les appareils équipés d'un gyroscope.

Barre d'action

ActionBar a été mis à jour pour prendre en charge plusieurs nouveaux comportements. La plupart Il est important de noter que le système gère parfaitement la taille et la configuration de la barre d'action lorsqu'elle s'exécute sur des écrans plus petits afin d’offrir 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), la barre d'action les onglets de navigation s'affichent dans une « barre empilée », qui apparaît juste en dessous de la barre d'action principale. Vous pouvez activer une barre d'action fractionnée 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 comprend plusieurs tâches, elles ne s'afficheront pas toutes dans la barre d'action sur un écran étroit, de sorte que le système en place davantage dans le menu à développer. Cependant, 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 barre séparée 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, procédez comme suit : mais que vous n'avez pas besoin de la barre d'action principale en haut (vous voulez que seuls les onglets s'affichent en haut), activez la barre d'action de fractionnement comme décrit ci-dessus et appelez setDisplayShowHomeEnabled(false) pour désactiver 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 des é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 des actions pour accéder plus rapidement au partage avec cette application.

Pour déclarer un fournisseur d'action pour une tâche, incluez android:actionProviderClass dans l'élément <item> du menu d'options de votre activité, avec le nom de classe de l'action "provider" 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 un exemple d'utilisation de ShareActionProvider, consultez ActionBarShareActionProviderActivity dans ApiDemos.

Vues d'action 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 le SearchView compatible lorsqu'elle est utilisée comme vue d'action. Désormais, vous pouvez ajouter une vue "Action" pour n'importe quelle action passer de l'état développé (la vue des actions est visible) à 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 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/logo se comporte comme un bouton permettant de revenir à la page d'accueil ou de revenir en haut (passez "true" pour qu'il se comporte comme un bouton).
  • setIcon() et setLogo() vous permettent de définir l'icône ou le logo de la barre d'action au moment de l'exécution.
  • Fragment.setMenuVisibility() vous permet d'activer ou 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 un format la grille. Contrairement à TableLayout, GridLayout repose sur un graphe plat et n'utilise pas de vues intermédiaires, telles que les lignes d'un tableau, pour structurer le tableau. À 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ées 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, les animer avec 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.

Changer de widget

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. s'affiche sur le bouton lorsque le mode est activé ou désactivé. L'attribut android:text inclut également permet d'ajouter un libellé à côté de l'interrupteur.

Pour un exemple d'utilisation de commutateurs, consultez le fichier de mise en page switches.xml et les commutateurs correspondants .

Android 3.0 a introduit PopupMenu pour créer de courts menus contextuels qui apparaissent à un point d'ancrage que vous spécifiez (généralement à l'endroit où l'élément sélectionné est 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 aussi créer un PopupMenu.OnDismissListener qui reçoit une 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 le des préférences pour permettre aux utilisateurs d'activer ou de désactiver un paramètre sans avoir à ouvrir des préférences ou une boîte de dialogue. 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 changent 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". Cependant, vous n'avez pas à vous en soucier si votre application existante propose un menu d'options et s'attend à ce qu'il y ait un Bouton "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 donner 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'interface utilisateur 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'interface utilisateur système appelée barre de navigation. Toi peut considérer la barre de navigation comme une version réglée de la barre système conçue pour des téléphones portables. Il fournit des commandes de navigation pour les appareils qui n'ont pas d'équivalent matériel pour naviguer dans le système, mais qui laisse de côté l'UI de notification de la barre système et les commandes des paramètres. Ainsi, un dispositif qui fournit la navigation a également la barre d'état en haut.

À ce jour, vous pouvez encore 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 a été modifiée pour mieux refléter le comportement des deux et la barre de navigation:

  • L'option SYSTEM_UI_FLAG_LOW_PROFILE remplace l'option STATUS_BAR_HIDDEN. Lorsqu'il est défini, cet indicateur active l'option "Profil discret" pour la barre système ou barre de navigation. Les boutons de navigation s'assombrissent et les autres éléments de la barre système sont également masqués. Activation... Cela permet de créer des jeux plus immersifs sans distraction de la navigation 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 soient visibles.
  • SYSTEM_UI_FLAG_HIDE_NAVIGATION est une nouvelle option qui demande la barre de navigation sont complètement masquées. Sachez que cela ne s'applique qu'à la barre de navigation. utilisé par certains téléphones (la barre système n'est pas masquée 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 utile principalement pour la lecture de vidéos ou dans d'autres cas où l'intégralité de l'écran est nécessaire, mais où l'entrée utilisateur est n'est pas obligatoire.

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é. La gestionnaire de fenêtres combine (OU) tous les indicateurs de toutes les vues de votre fenêtre et et les appliquer à l'UI du système tant que la 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 avec le curseur, ainsi que les nouveaux événements de stylet et de bouton de la souris.

Événements de pointage

La classe View prend désormais en charge la fonction "hover" pour des interactions plus riches à l'aide de dispositifs de pointeur (comme une souris ou d'autres périphériques qui pilotent un élément à l'écran) curseur).

Pour recevoir des événements de pointage sur une vue, implémentez View.OnHoverListener et l'enregistrer auprès de setOnHoverListener(). Lorsque vous survolez se produit sur la vue, votre écouteur reçoit un appel à onHover(), qui fournit le View qui a reçu l'événement et une MotionEvent décrivant le type d'événement de pointage. qui s'est produit. Il peut s'agir de l'un des événements 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 dont l'apparence change en fonction de la l'état actuel, vous pouvez maintenant utiliser l'attribut android:state_hovered dans un drawable de liste d'états pour fournissent un drawable d'arrière-plan différent lorsqu'un curseur pointe sur la vue.

Pour obtenir 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 périphérique d'entrée à stylet tel qu'un numériseur. un périphérique de tablette ou un écran tactile compatible avec les stylets.

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 passe au-dessus du numérique, les applications reçoivent le passage de la souris. des événements comme lorsqu'un pointeur de souris était déplacé sur l'écran lorsqu'aucun bouton doivent appuyer.

Votre application peut faire la distinction entre la saisie au doigt, à la souris, au stylet et à la gomme en interrogeant les "type d'outil" associé à chaque pointeur dans un élément 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 sur lesquels vous appuyez en interrogeant le bouton État : 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" mappés automatiquement aux clés KEYCODE_BACK et KEYCODE_FORWARD. Votre application peut gérer ces clés avec la navigation vers l'avant et l'arrière à l'aide du bouton 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 en utilisant 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 y a aussi permet de transmettre des références de champ/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, vous devez vous avez déjà effectué cette opération:

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 définir un autre code bar, il n'y avait aucun moyen de le faire avec une version antérieure à Android 4.0.

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

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 Property. Vous pouvez donc créer un ObjectAnimator avec un Property, qui est plus rapide, plus efficace et plus sûr que la méthode basée sur des chaînes approche.

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 application a défini targetSdkVersion ou minSdkVersion jusqu'à “14" ou version ultérieure. L'accélération matérielle se traduit généralement par des animations plus fluides le défilement, ainsi que des performances globales et une meilleure réactivité face aux interactions des utilisateurs.

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 identifiants indirects. Android utilisé 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 afin de 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.

Cette modification de l'implémentation JNI n'affecte que les applications qui ciblent Android 4.0 en définissant soit targetSdkVersion ou minSdkVersion sur “14" ou plus. 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

  • WebKit mis à jour à la version 534.30
  • Compatibilité avec les polices indo-aryennes (devanagari, bengali et tamoul, y compris les caractères complexes) nécessaire pour combiner les glyphes) dans WebView et dans 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 une vue détaillée de toutes les modifications apportées aux API sous Android 4.0 (niveau d'API), 14), consultez le rapport sur les différences de l'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 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 désormais disponibles sur les téléphones portables:

Android 3.0
  • Fragment: composant de framework qui vous permet de séparer des d'une activité en modules autonomes définissant leur propre interface utilisateur 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 mode asynchrone chargement de données combiné à des composants d'interface utilisateur pour les charger dynamiquement sans bloquer 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 tronquées peuvent être du texte brut, un URI ou un intent. Consultez le Copier et coller dans le guide du développeur.
  • 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 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 Property Animation .
  • 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. Il en résulte avec des animations et un défilement plus fluides, et de meilleures performances globales et une meilleure réponse à l'utilisateur d'interaction.

    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 protocole PTP (Picture Transfer Protocol) de la spécification MTP (Media Transfer Protocol). Consultez le 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 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 android.net.rtp.
  • Compatibilité avec les joysticks et d'autres entrées de mouvement génériques.
  • Consultez la page sur la plate-forme Android 3.1. pour de nombreuses autres nouvelles API.
Android 3.2
  • Les nouveaux écrans sont compatibles avec des API qui vous permettent de mieux contrôler la façon dont vos applications affiché sur différentes tailles d'écran. L'API étend le modèle existant de prise en charge des écrans grâce au Possibilité 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é (par exemple, 600 dp ou 720 dp de large), plutôt que par leur tailles d'écran (telles que grande ou XL). 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> dans déclarer les exigences concernant l'orientation d'écran en mode paysage ou portrait ;
  • La "taille de l'écran" de l'appareil la configuration change désormais lors de l'orientation de l'écran le changement. Si votre application cible le niveau d'API 13 ou supérieur, vous devez gérer le "screenSize" modification de configuration si vous souhaitez également gérer le changement de configuration de "orientation". Voir android:configChanges pour en savoir plus.
  • Consultez la page sur la plate-forme Android 3.2. pour les autres nouvelles API.

Niveau d'API

Un nombre entier est attribué à l'API Android 4.0 (14) qui est stocké dans le système. Cet identifiant, appelé "niveau d'API", permet au système de déterminer correctement une application est compatible avec le système, avant son installation.

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

Pour plus d'informations, consultez la page Qu'est-ce que l'API ? Niveau ?