API Android 2.3

Niveau d'API:9

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

Présentation de l'API

Les sections ci-dessous offrent un aperçu technique des nouveautés pour les développeurs dans la version 2.3, y compris les nouvelles fonctionnalités et les modifications apportées au cadre 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 permet développeurs créent des applications de téléphonie Internet. Grâce à l'API, les applications peuvent offrir les fonctionnalités d'appel vocal sans avoir à gérer de sessions, de transport de la communication ou de l'audio, ceux-ci sont gérés de manière transparente par l'API et les services SIP de la plateforme.

L'API SIP est disponible dans le package android.net.sip. La classe de clé est SipManager, que les applications utilisent pour configurer et gérer des profils SIP, puis pour lancer et recevoir des appels audio. Une fois l'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é. Pour cette raison, applications doivent utiliser la méthode isApiSupported() pour vérifier si la prise en charge SIP est disponible, avant ce qui expose la fonctionnalité d'appel aux utilisateurs.

Pour utiliser l'API SIP, les applications doivent demander l'autorisation à l'utilisateur avant déclarer <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 afin que leurs applications ne soient pas visibles par les utilisateurs dont les appareils n'incluent pas la pile et les services SIP de la plate-forme. Pour demander le 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 à 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 tags lorsqu'ils se trouvent à portée. Lorsqu'elle détecte une balise, la plate-forme en informe les applications en diffusant un intent, en ajoutant les messages NDEF de la balise à l'intent en tant qu'éléments supplémentaires. 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 une par Intent, les applications extraient les messages NDEF, les stockent, alertent utilisateur, ou les gérer d’une autre manière.

L'API NFC est disponible dans le package android.nfc. Les principales classes sont les suivantes :

  • NfcAdapter, qui représente le matériel NFC de l'appareil.
  • NdefMessage, qui représente un message de données NDEF, le format standard dans lequel les "enregistrements" le transfert de données sont transmis entre appareils et tags. Les applications peuvent recevoir ces messages à partir d'intents ACTION_TAG_DISCOVERED.
  • NdefRecord, transmis 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 dans le matériel de l'appareil, donc la compatibilité 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, quel que soit le matériel sous-jacent compatible.

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

De plus, les développeurs peuvent demander un filtrage sur Google Play afin 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 consulter un exemple d'application qui utilise l'API NFC, consultez NFCDemo.

Gyroscope et autres capteurs

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

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

Les développeurs peuvent demander un filtrage sur Google Play afin que leurs applications ne soient pas visibles par les utilisateurs dont les appareils ne disposent pas de capteur gyroscopique. 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 toutes les caméras disponibles sur un appareil, que ce soit pour la capture de photos ou de vidéos. Camera permet aux applications d'interroger le nombre de caméras disponibles et les caractéristiques uniques de chacune d'elles.

  • La nouvelle classe Camera.CameraInfo stocke les caractéristiques de position d'une caméra (orientation, avant 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 celle dont elles ont besoin.
  • La nouvelle méthode get() permet les applications récupèrent un CamcorderProfile pour un appareil photo spécifique.
  • Le nouveau getJpegEncodingQualityParameter() permet aux applications d'obtenir l'image fixe le niveau de qualité d'un appareil photo spécifique.

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

L'API Camera offre également les avantages suivants:

Effets audio mixables

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

Pour consulter un exemple de code pour les effets audio, consultez AudioFxDemo.java dans l'application exemple ApiDemos.

Le framework pour les médias 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 l'orientation à MediaRecorder lors de l'enregistrement 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é vers un fichier de destination particulier. DownloadManager effectue le téléchargement en arrière-plan, gère les interactions HTTP et réessaie les téléchargements en cas d'échec, de modification de la connectivité ou de redémarrage du système.

  • Les applications peuvent obtenir une instance de DownloadManager en appelant getSystemService(String) et en transmettant DOWNLOAD_SERVICE Les applications qui demandent les téléchargements via cette API doivent enregistrer un broadcast receiver pour ACTION_NOTIFICATION_CLICKED, afin de gérer lorsque l'utilisateur clique sur un téléchargement en cours dans une notification ou à partir du UI des téléchargements.
  • La classe DownloadManager.Request permet à une votre application fournissent toutes les informations nécessaires pour demander un nouveau téléchargement, comme l'URI de la requête et la destination de téléchargement. Un URI de requête est le seul élément obligatoire . Notez que la destination de téléchargement par défaut est un volume partagé dans lequel le système peut supprimer votre fichier s'il a besoin de récupérer de l'espace pour l'utilisation du système. Pour le stockage persistant d'un téléchargement, spécifiez une destination de téléchargement sur un stockage externe (voir setDestinationUri(Uri)).
  • La classe DownloadManager.Query fournit des méthodes qui permettent à une application de rechercher 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 fonctionnalité système appelée StrictMode. Lorsqu'il est implémenté dans une application, StrictMode détecte et avertit le développeur d'une activité disque ou réseau accidentelle qui pourrait dégrader les performances de l'application, comme une activité qui se déroule sur le thread principal de l'application (où les opérations de l'UI sont reçues et des animations sont également effectuées). Les développeurs peuvent évaluer les problèmes d'utilisation du réseau et du disque soulevés dans StrictMode et les corriger si nécessaire, ce qui permet de maintenir le thread principal plus réactif et d'empêcher les boîtes de dialogue ANR d'être affichées aux utilisateurs.

  • StrictMode est la classe principale et l'intégration principale. avec le système et la VM. La classe fournit des méthodes pratiques en gérant 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 instances de thread et de VM.

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

Framework d'UI

  • 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 ce mode, contrôler le 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, comme l'animation, le rebond 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 overScrollMode, overScrollFooter et Attributs overScrollHeader pour les éléments <ListView>, pour contrôler le comportement du défilement hors limites.
  • Prise en charge du filtrage tactile
    • La prise en charge du filtrage tactile, qui permet à une application d'améliorer la sécurité des vues qui donnent accès à des fonctionnalités sensibles. Par exemple : Le filtrage tactile est adapté pour garantir la sécurité des actions des utilisateurs, telles que une demande d'autorisation, un achat ou un clic publicitaire. Pour plus de détails, reportez-vous à la section Afficher le cours documentation.
    • Nouvel attribut filterTouchesWhenObscured pour les éléments de vue, qui indique si les gestes doivent être filtrés lorsque la fenêtre de la vue est masquée par une autre fenêtre visible. Si la valeur est "true", la vue n'est pas recevoir des pressions chaque fois qu'un toast, une boîte de dialogue ou une autre fenêtre s'affiche au-dessus de la dans la fenêtre d'affichage. Reportez-vous à la section Afficher la sécurité documentation pour plus de détails.

    Pour voir un exemple de code de 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'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 stocke des informations sur les fonctionnalités d'un périphérique d'entrée spécifique et fournit des méthodes permettant aux applications de déterminer comment interpréter les événements d'une périphérique d'entrée.
  • Événements de mouvement améliorés
    • L'API MotionEvent est étendue pour inclure "l'ID du pointeur" ce qui permet aux applications de suivre chaque doigt lorsqu'il de haut en 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 permettant de générer des événements de mouvement avec les nouvelles informations d'ID de pointeur, synthétisant les identifiants lorsque les nouveaux pointeurs sont inactifs. Le système suit plusieurs ID de pointeur séparément lors d'un événement de mouvement et assure une continuité appropriée des pointeurs en évaluant la distance entre le dernier et le prochain ensemble de pointeurs.
  • Commandes de sélection de texte
    • Une nouvelle méthode setComposingRegion permet à une application de marquer une région de texte comme texte en cours de composition, tout en conservant le style actuel. A La méthode getSelectedText renvoie le texte sélectionné à la 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 éléments drawable qui seront utilisés pour afficher les ancrages de sélection de texte et le style de la fenêtre contenante.
  • Commandes relatives à l'activité
  • Styles de texte et d'icône des notifications

    • Très grands écrans

    La plate-forme est désormais compatible avec les très grandes tailles d'écran, comme celles que l'on peut trouver sur les tablettes. Les développeurs peuvent indiquer que leurs applications conçu pour prendre en charge des écrans de très grande taille en ajoutant un élément <supports screens ... android:xlargeScreens="true"> à son fichier manifeste . Les applications peuvent utiliser un nouveau qualificatif de ressource, xlarge, pour aux ressources de tag spécifiques aux très grands écrans. Pour savoir comment prendre en charge les écrans très grands et d'autres tailles d'écran, consultez la section Compatibilité avec plusieurs écrans.

    Graphiques

    Fournisseurs de contenu

    • Nouvelle classe de fournisseur AlarmClock pour régler une alarme ou la gérer. Le fournisseur contient une action d'intent ACTION_SET_ALARM et des éléments supplémentaires 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é qui nécessite l'autorisation SET_ALARM. Les applications qui souhaitent créer l'alarme doit utiliser Context.startActivity(), pour que l'utilisateur puisse choisir l'application de réveil à utiliser.
    • MediaStore est compatible avec une nouvelle action d'intent, PLAY_FROM_SEARCH, qui permet à une application de rechercher des contenus multimédias 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 lecteur multimédia d'ignorer les éléments multimédias du répertoire contenant et de ses sous-répertoires. Les développeurs peuvent l'utiliser pour éviter que des graphiques n'apparaissent dans la galerie et pour empêcher les sons et la musique de l'application de s'afficher dans l'application Musique.
    • 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 "Gérer les applications".
    • Le fournisseur ContactsContract ajoute le type de données ContactsContract.CommonDataKinds.SipAddress pour stocker l'adresse SIP (téléphonie Internet) d'un contact.

    Position

    • LocationManager effectue désormais le suivi des applications qui entraînent des wakelocks ou des verrous Wi-Fi en fonction WorkSource, une classe gérée par le système qui identifie le application.

      LocationManager suit tous les clients qui demandent des mises à jour périodiques et en informe ses fournisseurs en tant que paramètre WorkSource lors de la définition de leurs délais de mise à jour minimum. Le fournisseur de géolocalisation utilise WorkSource pour suivre des wakelocks et des verrouillages Wi-Fi initiés par une application et les ajoute au l'utilisation de la batterie indiquée dans la section "Gérer les applications".

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

    Stockage

    • Android 2.3 ajoute un nouveau StorageManager qui prend en charge les fichiers OBB (Opaque Binary Blob). Bien que la plate-forme soit compatible avec les fichiers OBB sous Android 2.3, les outils de développement permettant de créer et de gérer des fichiers OBB ne seront disponibles qu'au début de l'année 2011.
    • La plate-forme Android 2.3 est officiellement compatible avec les appareils qui n'incluent pas de carte 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 déterminer si une carte SD physique est présente.

    Gestionnaire de packages

    • Nouvelles constantes permettant de déclarer des fonctionnalités matérielles et logicielles. Consultez la liste dans la section Nouvelles constantes de fonctionnalités ci-dessous.
    • PackageInfo ajoute de nouveaux champs firstInstallTime et lastUpdateTime qui stockent l'heure de la l'installation du package et la dernière mise à jour.
    • Nouvelle méthode getProviderInfo() permettant de récupérer toutes les informations connues sur une classe de fournisseur de contenu particulière.

    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 d’embrouillage primaire de la cellule de diffusion sur un réseau UMTS.

    Accès natif au cycle de vie de l'activité, Windows

    Android 2.3 expose un large ensemble d'API aux applications qui utilisent du code natif. Voici quelques classes de framework qui peuvent intéresser ces applications :

    • NativeActivity est un nouveau type de classe d'activité, 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 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. Ils 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 gérer une SurfaceHolder.
    • Les nouvelles méthodes takeInputQueue et takeSurface() dans Window permettent au code natif de gérer événements et surfaces.

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

    Dalvik Runtime

    Nouveaux éléments et attributs du fichier manifeste

    • Nouvel attribut xlargeScreens pour l'élément <supports-screens>, afin d'indiquer si l'application est compatible avec les formats d'écran très grands. 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 le paramètre écran en mode paysage, tourné dans le sens opposé au sens normal en mode paysage.
      • "reversePortrait" : l'activité souhaite que l'écran soit en mode portrait, 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 l'orientation de l'écran.
      • "sensorPortrait" : l'activité souhaite que le paramètre l'écran en mode portrait, mais vous pouvez utiliser le capteur pour changer de direction. 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 généralement pas la rotation à 180 degrés.

    Nouvelles autorisations

    • com.android.permission.SET_ALARM : permet à une application de diffuser un intent pour définir une alarme pour l'utilisateur. Une activité qui gère l'action d'intent SET_ALARM devrait exiger 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 les NFC API pour lire les tags NFC.

    Nouvelles constantes de fonctionnalités

    La plate-forme ajoute plusieurs nouvelles fonctionnalités matérielles que les développeurs peuvent déclarer dans leurs fichiers manifestes comme requis par leurs applications. Ce 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 de fonctionnalités et leur utilisation pour le filtrage, consultez la documentation sur <uses-feature>.

    Rapport sur les différences entre les API

    Pour obtenir un aperçu détaillé de toutes les modifications apportées aux API dans Android 2.3 (niveau d'API 9), consultez le rapport de différences des API.

    Niveau d'API

    La plate-forme Android 2.3 fournit une version mise à jour de l'API du framework. L'API Android 2.3 se voit attribuer un identifiant entier (9) stocké dans le système lui-même. Cet identifiant, appelé "niveau d'API", permet pour déterminer correctement si une application est compatible avec le système avant d'installer l'application.

    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 du SDK Android 2.3. Selon 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 s'exécuter uniquement 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 ?