API Android 2.3

Niveau d'API:9

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

Présentation de l'API

Les sections ci-dessous fournissent un aperçu technique des nouveautés de la version 2.3 pour les développeurs, y compris des nouvelles fonctionnalités et des modifications apportées à l'API de framework depuis la version précédente.

VoIP basée sur SIP

La plate-forme inclut désormais une pile de protocoles SIP et une API de framework qui permettent aux développeurs de créer des applications de téléphonie Internet. Grâce à cette API, les applications peuvent proposer des fonctionnalités d'appel vocal sans avoir à gérer les sessions, la communication au niveau du transport ni l'audio. Ces fonctionnalités sont gérées de manière transparente par l'API et les services SIP de la plate-forme.

L'API SIP est disponible dans le package android.net.sip. La classe de clé est SipManager. Elle permet aux applications de configurer et de gérer les profils SIP, puis d'effectuer des appels audio et de recevoir des appels audio. Une fois un appel audio établi, les applications peuvent couper le son des appels, activer le mode haut-parleur, envoyer des tonalités DTMF, etc. Les applications peuvent également utiliser SipManager pour créer des connexions SIP génériques.

La pile SIP et les services sous-jacents de la plate-forme sont disponibles sur les appareils à la discrétion du fabricant et de l'opérateur associé. C'est pourquoi les applications doivent utiliser la méthode isApiSupported() pour vérifier si la prise en charge SIP est disponible, avant d'exposer la fonctionnalité d'appel aux utilisateurs.

Pour utiliser l'API SIP, les applications doivent demander l'autorisation de l'utilisateur en déclarant <uses-permission android:name="android.permission.INTERNET"> et <uses-permission android:name="android.permission.USE_SIP"> dans leurs fichiers manifestes.

En outre, les développeurs peuvent demander un filtrage sur Google Play, de sorte que leurs applications ne soient pas visibles par les utilisateurs dont les appareils n'incluent pas la pile SIP ni les services de la plate-forme. Pour demander un filtrage, ajoutez <uses-feature android:name="android.software.sip" android:required="true"> et <uses-feature android:name="android.software.sip.voip"> au fichier manifeste de l'application.

Pour en savoir plus, consultez le guide du développeur SIP.

Technologie NFC (communication en champ proche)

Android 2.3 inclut une pile NFC et une API de framework qui permettent aux développeurs de lire les tags NDEF détectés lorsqu'un utilisateur touche un appareil compatible NFC pour taguer des éléments intégrés dans des autocollants, des affiches intelligentes et même d'autres appareils.

La plate-forme fournit les services NFC sous-jacents qui fonctionnent avec le matériel de l'appareil pour détecter les balises lorsqu'elles sont à portée. Lors de la découverte d'une balise, la plate-forme notifie les applications en diffusant un intent, en ajoutant les messages NDEF de la balise à l'intent en tant qu'extras. Les applications peuvent créer des filtres d'intent pour reconnaître et gérer les tags et les messages ciblés. Par exemple, après avoir reçu un tag par un intent, les applications extraient les messages NDEF, les stockent, envoient une alerte à l'utilisateur ou les traitent d'autres manières.

L'API NFC est disponible dans le package android.nfc. Les classes de clés sont les suivantes:

  • NfcAdapter, qui représente le matériel NFC sur l'appareil.
  • NdefMessage, qui représente un message de données NDEF, le format standard dans lequel des "enregistrements" contenant des données sont transmis entre les appareils et les tags. Les applications peuvent recevoir ces messages à partir des intents ACTION_TAG_DISCOVERED.
  • NdefRecord, envoyé dans un NdefMessage, qui décrit le type de données partagées et transporte les données elles-mêmes.

La communication NFC repose sur la technologie sans fil intégrée au matériel de l'appareil. Par conséquent, la prise en charge des fonctionnalités NFC de la plate-forme sur des appareils spécifiques est déterminée par leurs fabricants. Pour déterminer la compatibilité NFC sur l'appareil actuel, les applications peuvent appeler isEnabled() pour interroger NfcAdapter. L'API NFC est toutefois toujours présente, quelle que soit la compatibilité matérielle sous-jacente.

Pour utiliser l'API NFC, les applications doivent demander l'autorisation de l'utilisateur en déclarant <uses-permission android:name="android.permission.NFC"> dans leurs fichiers manifestes.

En outre, les développeurs peuvent demander un filtrage sur Google Play, de sorte que leurs applications ne soient pas visibles par les utilisateurs dont les appareils ne sont pas compatibles avec la technologie NFC. Pour demander un filtrage, ajoutez <uses-feature android:name="android.hardware.nfc" android:required="true"> au fichier manifeste de l'application.

Pour examiner un exemple d'application qui utilise l'API NFC, consultez la démonstration NFC.

Gyroscope et autres capteurs

Android 2.3 prend en charge la plate-forme et l'API pour plusieurs nouveaux types de lecture de capteurs : gyroscope, vecteur de rotation, accélération linéaire, gravité et baromètre. Les développeurs peuvent utiliser les nouvelles mesures des capteurs pour créer des applications qui réagissent rapidement et en douceur à des changements précis de position et de mouvement de l'appareil. L'API Sensor signale les modifications apportées au gyroscope et aux autres capteurs aux applications intéressées, qu'elles s'exécutent sur le framework de l'application ou dans du code natif.

Notez que l'ensemble spécifique de capteurs matériels disponible sur un appareil donné varie à la discrétion du fabricant.

Les développeurs peuvent demander un filtrage sur Google Play, de sorte que leurs applications ne soient pas visibles par les utilisateurs dont les appareils ne sont pas équipés de capteur de gyroscope. Pour ce faire, ajoutez <uses-feature android:name="android.hardware.sensor.gyroscope" android:required="true"> au fichier manifeste de l'application.

Pour en savoir plus sur l'API, consultez Sensor.

Compatibilité avec plusieurs caméras

Les applications peuvent désormais utiliser tous les appareils photo disponibles sur un appareil pour la capture photo ou vidéo. Camera permet aux applications d'interroger le nombre d'appareils photo disponibles et les caractéristiques uniques de chacun d'eux.

  • La nouvelle classe Camera.CameraInfo stocke les caractéristiques de position d'une caméra (orientation, face ou arrière).
  • Les nouvelles méthodes getNumberOfCameras() et getCameraInfo() de la classe Camera permettent aux applications d'interroger les caméras disponibles et d'ouvrir l'appareil photo dont elles ont besoin.
  • La nouvelle méthode get() permet aux applications de récupérer un CamcorderProfile pour un appareil photo spécifique.
  • Le nouveau getJpegEncodingQualityParameter() permet aux applications d'obtenir le niveau de qualité de capture d'images fixes pour un appareil photo spécifique.

Pour examiner un exemple de code permettant d'accéder à une caméra frontale, consultez CameraPreview.java dans l'exemple d'application ApiDemos.

L'API Camera ajoute également:

Effets audio mixables

Le framework multimédia de la plate-forme est compatible avec de nouveaux effets audio par titre ou globaux, tels que l'amplification des basses, la virtualisation du casque, l'égalisation et la réverbération.

Pour examiner un exemple de code pour des effets audio, consultez AudioFxDemo.java dans l'exemple d'application ApiDemos.

Le framework multimédia ajoute également:

  • Nouvelle prise en charge de la balise d'altitude dans les métadonnées EXIF pour les fichiers JPEG. Nouvelle méthode getAltitude() pour récupérer la valeur de la balise d'altitude EXIF.
  • La nouvelle méthode setOrientationHint() permet à une application d'indiquer à MediaRecorder l'orientation pendant la capture vidéo.

Gestionnaire de téléchargement

La plate-forme inclut un nouveau service système DownloadManager qui gère les téléchargements HTTP de longue durée. Les applications peuvent demander qu'un URI soit téléchargé dans un fichier de destination particulier. DownloadManager effectue le téléchargement en arrière-plan, en prenant en charge les interactions HTTP et les nouvelles tentatives de téléchargement après des échecs, ou en cas de changement de connectivité et de redémarrage du système.

  • Les applications peuvent obtenir une instance de la classe DownloadManager en appelant getSystemService(String) et en transmettant DOWNLOAD_SERVICE. Les applications qui demandent des téléchargements via cette API doivent enregistrer un broadcast receiver pour ACTION_NOTIFICATION_CLICKED, afin de gérer de manière appropriée lorsque l'utilisateur clique sur un téléchargement en cours d'exécution dans une notification ou à partir de l'UI des téléchargements.
  • La classe DownloadManager.Request permet à une application de fournir toutes les informations nécessaires pour demander un nouveau téléchargement, telles que l'URI de la requête et la destination du téléchargement. L'URI de la requête est le seul paramètre obligatoire. Notez que la destination de téléchargement par défaut est un volume partagé sur lequel le système peut supprimer votre fichier s'il a besoin de récupérer de l'espace pour l'utiliser. Pour le stockage persistant d'un téléchargement, spécifiez une destination de téléchargement dans le stockage externe (voir setDestinationUri(Uri)).
  • La classe DownloadManager.Query fournit des méthodes qui permettent à une application d'interroger et de filtrer les téléchargements actifs.

Mode strict

Pour aider les développeurs à surveiller et à améliorer les performances de leurs applications, la plate-forme propose une nouvelle installation système appelée StrictMode. Lorsqu'il est implémenté dans une application, le StrictMode détecte et avertit le développeur de toute activité accidentelle sur le disque ou le réseau susceptible de dégrader les performances de l'application, telle que l'activité sur le thread principal de l'application (où les opérations d'interface utilisateur sont reçues et les animations sont également en cours). Les développeurs peuvent évaluer les problèmes d'utilisation du réseau et du disque soulevés en StrictMode, et les corriger si nécessaire. Cela permet de maintenir le thread principal plus réactif et d'empêcher l'affichage de boîtes de dialogue ANR.

  • StrictMode est la classe principale et constitue le principal point d'intégration avec le système et la VM. Cette classe fournit des méthodes pratiques pour gérer les règles de thread et de VM qui s'appliquent à l'instance.
  • StrictMode.ThreadPolicy et StrictMode.VmPolicy contiennent les règles que vous définissez et appliquez aux threads et aux instances de VM.

Pour en savoir plus sur l'utilisation du StrictMode pour optimiser votre application, consultez la documentation de la classe et l'exemple de code sur android.os.StrictMode.

Framework d'interface utilisateur

  • Prise en charge du défilement hors limites
    • Prise en charge du défilement hors limites dans les vues et les widgets. Dans les vues, les applications peuvent activer/désactiver le défilement hors limites pour une vue donnée, définir le mode de défilement hors limites, contrôler la distance de défilement hors limites et gérer les résultats du défilement hors limites.
    • Dans les widgets, les applications peuvent contrôler les caractéristiques de défilement hors limites, telles que l'animation, le retour à la source et la distance de défilement hors limites. Pour en savoir plus, consultez android.view.View et android.widget.OverScroller.
    • ViewConfiguration fournit également les méthodes getScaledOverflingDistance() et getScaledOverscrollDistance().
    • Nouveaux attributs overScrollMode, overScrollFooter et overScrollHeader pour les éléments <ListView> permettant de contrôler le comportement de défilement hors limites
  • Compatibilité avec le filtrage tactile
    • Nouvelle prise en charge du filtrage tactile, qui permet à une application d'améliorer la sécurité des vues donnant accès aux fonctionnalités sensibles. Par exemple, le filtrage tactile est adapté pour assurer la sécurité des actions des utilisateurs, telles que l'octroi d'une demande d'autorisation, l'achat d'un produit ou le clic sur une publicité. Pour en savoir plus, consultez la documentation sur la classe View.
    • Nouvel attribut filterTouchesWhenObscured pour les éléments de vue, qui indique s'il faut filtrer les gestes lorsque la fenêtre de la vue est masquée par une autre fenêtre visible. Lorsque ce paramètre est défini sur "true", la vue ne reçoit pas de contact chaque fois qu'un toast, une boîte de dialogue ou une autre fenêtre apparaît au-dessus de la fenêtre de la vue. Pour en savoir plus, consultez la documentation sur la sécurité.

    Pour examiner un exemple de code pour le filtrage tactile, consultez SecureView.java dans l'exemple d'application ApiDemos.

  • Gestion des événements améliorée
    • Nouvelle classe de base pour les événements d'entrée : InputEvent. La classe fournit des méthodes qui permettent aux applications de déterminer la signification de l'événement, par exemple en interrogeant l'élément InputDevice à l'origine de l'événement. KeyEvent et MotionEvent sont des sous-classes de InputEvent.
    • Nouvelle classe de base pour les périphériques d'entrée : InputDevice. La classe stocke des informations sur les fonctionnalités d'un périphérique d'entrée particulier et fournit des méthodes permettant aux applications de déterminer comment interpréter les événements d'un périphérique d'entrée.
  • Amélioration des événements de mouvement
    • L'API MotionEvent est étendue pour inclure des informations sur l'ID du pointeur, ce qui permet aux applications de suivre chaque doigt lorsqu'il se déplace vers le haut et vers le bas. La classe ajoute diverses méthodes qui permettent à une application de fonctionner efficacement avec les événements de mouvement.
    • Le système d'entrée dispose désormais d'une logique pour générer des événements de mouvement avec les nouvelles informations d'ID de pointeur, en synthétisant les identifiants lorsque de nouveaux pointeurs sont arrêtés. Le système suit plusieurs ID de pointeur séparément lors d'un événement de mouvement et garantit une continuité correcte des pointeurs en évaluant la distance entre le dernier ensemble de pointeurs et le suivant.
  • Commandes de sélection de texte
    • Une nouvelle méthode setComposingRegion permet à une application de marquer une zone de texte comme étant celle de composition, en conservant le style actuel. Une méthode getSelectedText renvoie le texte sélectionné à l'application. Les méthodes sont disponibles dans BaseInputConnection, InputConnection et InputConnectionWrapper.
    • Nouveaux attributs textSelectHandle, textSelectHandleLeft, textSelectHandleRight et textSelectHandleWindowStyle pour <TextView>, permettant de référencer les drawables qui seront utilisés pour afficher les ancres de sélection de texte et le style de la fenêtre de conteneur.
  • Commandes relatives à l'activité
  • Styles de texte et d'icônes de notification

    • Très grands écrans

    La plate-forme est désormais compatible avec les très grands écrans, tels que ceux que l'on trouve sur les tablettes. Les développeurs peuvent indiquer que leurs applications sont conçues pour prendre en charge des écrans de très grande taille en ajoutant un élément <supports screens ... android:xlargeScreens="true"> à leurs fichiers manifestes. Les applications peuvent utiliser un nouveau qualificatif de ressource, xlarge, pour taguer les ressources spécifiques aux très grands écrans. Pour en savoir plus sur la compatibilité avec d'autres tailles d'écran, consultez la section Compatibilité avec plusieurs écrans.

    Graphismes

    Fournisseurs de contenu

    • Nouvelle classe de fournisseur AlarmClock pour définir ou gérer une alarme. Le fournisseur contient une action d'intent ACTION_SET_ALARM et des extras qui peuvent être utilisés pour démarrer une activité afin de définir une nouvelle alarme dans une application de réveil. Les applications qui souhaitent recevoir l'intent SET_ALARM doivent créer une activité nécessitant l'autorisation SET_ALARM. Les applications qui souhaitent créer une alarme doivent utiliser Context.startActivity() pour que l'utilisateur ait la possibilité de choisir quelle application de réveil utiliser.
    • MediaStore prend en charge une nouvelle action d'intent, PLAY_FROM_SEARCH, qui permet à une application de rechercher des contenus musicaux et de lire automatiquement le contenu du résultat lorsque cela est possible. Par exemple, une application peut déclencher cet intent à la suite d'une commande de reconnaissance vocale pour écouter de la musique.
    • MediaStore ajoute également un nouvel indicateur MEDIA_IGNORE_FILENAME qui indique au scanner multimédia d'ignorer les contenus multimédias dans le répertoire conteneur et ses sous-répertoires. Les développeurs peuvent l'utiliser pour éviter que des éléments graphiques apparaissent dans la galerie, et pour empêcher l'affichage des sons et de la musique de l'application dans l'application Music.
    • Le fournisseur Settings ajoute les nouvelles actions d'activité APPLICATION_DETAILS_SETTINGS et MANAGE_ALL_APPLICATIONS_SETTINGS, qui permettent à une application d'afficher l'écran d'informations d'une application spécifique ou l'écran de gestion des applications.
    • Le fournisseur ContactsContract ajoute le genre de données ContactsContract.CommonDataKinds.SipAddress pour stocker l'adresse SIP (téléphonie Internet) d'un contact.

    Position

    • LocationManager suit désormais les requêtes d'application qui entraînent des wakelocks ou des verrouillages Wi-Fi selon WorkSource, une classe gérée par le système qui identifie l'application.

      LocationManager effectue le suivi de tous les clients demandant des mises à jour périodiques et en informe ses fournisseurs en tant que paramètre WorkSource, lors de la définition des délais de mise à jour minimaux. Le fournisseur de localisation réseau utilise WorkSource pour suivre les activations et les verrouillages Wi-Fi initiés par une application, et les ajoute à l'utilisation de la batterie de l'application indiquée dans "Gérer les applications".

    • LocationManager ajoute plusieurs nouvelles méthodes qui permettent à une activité de recevoir des mises à jour de position périodiques ou ponctuelles en fonction des critères spécifiés (voir ci-dessous).
    • Une nouvelle classe Criteria permet à une application de spécifier un ensemble de critères pour la sélection d'un fournisseur de localisation. Par exemple, les fournisseurs peuvent être classés en fonction de la précision, de la consommation d'énergie, de leur capacité à signaler l'altitude, la vitesse, la direction et le coût.

    Stockage

    • Android 2.3 ajoute un nouveau StorageManager compatible avec les fichiers OBB (Opaque Binary Blob). Bien que la plate-forme OBB soit compatible avec Android 2.3, les outils de développement permettant de créer et de gérer des fichiers OBB ne seront pas disponibles avant début 2011.
    • La plate-forme Android 2.3 est officiellement compatible avec les appareils qui n'incluent pas de cartes SD (bien qu'elle fournisse une partition de carte SD virtuelle, lorsqu'aucune carte SD physique n'est disponible). Une méthode pratique, isExternalStorageRemovable(), permet aux applications de déterminer si une carte SD physique est présente.

    Gestionnaire de packages

    Téléphonie

    • TelephonyManager ajoute la constante NETWORK_TYPE_EVDO_B pour spécifier le type de réseau CDMA EvDo Rev B.
    • La nouvelle méthode getPsc() renvoie le code de brouillage principal de la cellule active sur un réseau UMTS.

    Accès natif au cycle de vie d'une activité, fenêtres

    Android 2.3 expose un large éventail d'API aux applications qui utilisent du code natif. Les types de framework d'intérêt pour ces applications sont les suivants:

    • NativeActivity est un nouveau type de classe Activity, dont les rappels de cycle de vie sont implémentés directement dans le code natif. Un NativeActivity et son code natif sous-jacent s'exécutent dans le système, tout comme les autres activités. Plus précisément, ils s'exécutent dans le processus système de l'application Android et sur le thread UI principal de l'application, et reçoivent les mêmes rappels de cycle de vie que les autres activités.
    • La nouvelle classe InputQueue et l'interface de rappel permettent au code natif de gérer la mise en file d'attente des événements.
    • La nouvelle interface SurfaceHolder.Callback2 permet au code natif de gérer un SurfaceHolder.
    • Les nouvelles méthodes takeInputQueue et takeSurface() dans Window permettent au code natif de gérer les événements et les surfaces.

    Pour en savoir plus sur l'utilisation du code natif ou pour télécharger le NDK, consultez la page NDK Android.

    Environnement d'exécution Dalvik

    Nouveaux éléments et attributs du fichier manifeste

    • Nouvel attribut xlargeScreens pour l'élément <supports-screens>, permettant d'indiquer si l'application est compatible avec les très grands écrans. Pour en savoir plus, consultez la section Compatibilité avec plusieurs écrans.
    • Nouvelles valeurs pour l'attribut android:screenOrientation de l'élément <activity> :
      • "reverseLandscape" : l'activité souhaite que l'écran soit en mode paysage, orienté dans le sens opposé au mode paysage normal.
      • "reversePortrait" : l'activité souhaite que l'écran soit en mode portrait, orienté dans le sens opposé au mode portrait standard.
      • "sensorLandscape" : l'activité souhaite que l'écran soit en mode paysage, mais peut utiliser le capteur pour modifier la direction vers laquelle l'écran est orienté.
      • "sensorPortrait" : l'activité souhaite que l'écran soit en mode portrait, mais peut utiliser le capteur pour changer la direction vers laquelle l'écran est orienté.
      • "fullSensor": l'orientation est déterminée par un capteur d'orientation physique. L'écran pivote en fonction de la façon dont l'utilisateur déplace l'appareil. Cela permet l'une des quatre rotations possibles, quelles que soient les actions habituelles de l'appareil (par exemple, certains appareils n'utilisent pas normalement la rotation à 180 degrés).

    Nouvelles autorisations

    • com.android.permission.SET_ALARM : permet à une application de diffuser un intent afin de définir une alarme pour l'utilisateur. Une activité qui gère l'action d'intent SET_ALARM doit nécessiter cette autorisation.
    • android.permission.USE_SIP : permet à une application d'utiliser SIP API pour passer ou recevoir des appels Internet.
    • android.permission.NFC : permet à une application d'utiliser NFC API pour lire les tags NFC.

    Nouvelles constantes de caractéristiques

    La plate-forme ajoute plusieurs nouvelles fonctionnalités matérielles que les développeurs peuvent déclarer comme requises par celles-ci dans les fichiers manifestes de leurs applications. Cela permet aux développeurs de contrôler le filtrage de leur application lorsqu'elle est publiée sur Google Play.

    Pour en savoir plus sur la déclaration des caractéristiques et leur utilisation pour le filtrage, consultez la documentation de <uses-feature>.

    Rapport sur les différences entre les API

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

    Niveau d'API

    La plate-forme Android 2.3 fournit une version mise à jour de l'API du framework. Un identifiant entier (9) est attribué à l'API Android 2.3, qui est 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 2.3 dans votre application, vous devez compiler l'application avec la bibliothèque Android fournie dans la plate-forme SDK Android 2.3. En fonction de vos besoins, vous devrez peut-être également ajouter un attribut android:minSdkVersion="9" à l'élément <uses-sdk> dans le fichier manifeste de l'application. Si votre application est conçue pour ne s'exécuter que sur Android 2.3 ou version ultérieure, déclarer l'attribut empêche son installation sur les versions antérieures de la plate-forme.

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