API Android 3.1

Niveau d'API:12

Pour les développeurs, la plate-forme Android 3.1 (HONEYCOMB_MR1) 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. La plate-forme téléchargeable ne comprend aucune bibliothèque externe.

Pour les développeurs, la plate-forme Android 3.1 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 3.1, 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 pour les développeurs sous Android 3.1, y compris les nouvelles fonctionnalités et les modifications apportées à l'API de framework depuis la version précédente.

API USB

Android 3.1 introduit de nouvelles API puissantes pour intégrer des périphériques connectés aux applications exécutées sur la plate-forme. Les API sont basées sur une pile USB (Universal Serial Bus) et sur les services intégrés à la plate-forme, y compris la prise en charge des interactions avec les hôtes USB et les appareils. À l'aide des API, les développeurs peuvent créer des applications capables de détecter, de communiquer et de gérer divers types d'appareils connectés via USB.

La pile et les API distinguent deux types de matériel USB de base, selon que l'appareil Android joue le rôle d'hôte ou que le matériel externe joue le rôle d'hôte:

  • Un périphérique USB est un matériel connecté qui dépend de l'appareil Android utilisé comme hôte. Par exemple, la plupart des périphériques d'entrée, des souris et des joysticks sont des périphériques USB, comme de nombreux appareils photo, hubs, etc.
  • Un accessoire USB est un matériel connecté doté d'un contrôleur hôte USB, alimentant le réseau et conçu pour communiquer avec les appareils Android via USB. Divers périphériques peuvent se connecter en tant qu'accessoires, des contrôleurs robotiques aux équipements de musique, en passant par les vélos d'appartement.

Pour les deux types (appareils USB et accessoires USB), les API USB de la plate-forme sont compatibles avec la détection par diffusion d'intent lorsqu'elles sont associées ou dissociées, ainsi qu'avec les interfaces, les points de terminaison et les modes de transfert standards (contrôle, groupé et interruption).

Les API USB sont disponibles dans le package android.hardware.usb. La classe centrale est UsbManager. Elle fournit des méthodes d'aide pour identifier les appareils USB et les accessoires USB et communiquer avec eux. Les applications peuvent acquérir une instance de UsbManager, puis interroger la liste des appareils ou accessoires associés, puis communiquer avec eux ou les gérer. UsbManager déclare également les actions d'intent diffusées par le système pour annoncer lorsqu'un appareil ou un accessoire USB est associé ou dissocié.

Voici d'autres classes:

  • UsbDevice, une classe représentant le matériel externe connecté en tant qu'appareil USB (l'appareil Android jouant le rôle d'hôte).
  • UsbAccessory, qui représente le matériel externe connecté en tant qu'hôte USB (l'appareil Android faisant office d'appareil USB).
  • UsbInterface et UsbEndpoint, qui permettent d'accéder aux interfaces et points de terminaison USB standards d'un appareil.
  • UsbDeviceConnection et UsbRequest, pour envoyer et recevoir des données et contrôler des messages vers ou depuis un appareil USB, de manière synchrone et asynchrone.
  • UsbConstants, qui fournit des constantes pour déclarer les types de points de terminaison, les classes d'appareils, etc.

Bien que la pile USB soit intégrée à la plate-forme, la compatibilité réelle avec les modes hôte USB et accessoire ouvert sur des appareils spécifiques est déterminée par leurs fabricants. En particulier, le mode hôte repose sur le matériel de manette USB approprié dans l'appareil Android.

En outre, les développeurs peuvent demander un filtrage sur Google Play, de sorte que leurs applications ne soient pas disponibles pour les utilisateurs dont les appareils n'offrent pas la prise en charge USB appropriée. Pour demander un filtrage, ajoutez l'un des éléments ci-dessous ou les deux au fichier manifeste de l'application, selon le cas:

  • Si l'application ne doit être visible que par les appareils compatibles avec le mode hôte USB (connexion d'appareils USB), déclarez cet élément:

    <uses-feature android:name="android.hardware.usb.host" android:required="true">

  • Si l'application ne doit être visible que sur les appareils compatibles avec les accessoires USB (connexion d'hôtes USB), déclarez cet élément:

    <uses-feature android:name="android.hardware.usb.accessory" android:required="true">

Pour obtenir des informations complètes sur le développement d'applications qui interagissent avec des accessoires USB, consultez la documentation destinée aux développeurs.

Pour examiner des exemples d'applications qui utilisent l'API hôte USB, consultez Test ADB et Missile Launcher.

API MTP/PTP

Android 3.1 expose une nouvelle API MTP qui permet aux applications d'interagir directement avec les caméras connectées et d'autres appareils PTP. La nouvelle API permet à une application de recevoir facilement des notifications lorsque des appareils sont connectés et supprimés, de gérer les fichiers et le stockage sur ces appareils, et de transférer des fichiers et des métadonnées vers et depuis ces appareils. L'API MTP met en œuvre le sous-ensemble PTP (Picture Transfer Protocol) de la spécification MTP (Media Transfer Protocol).

L'API MTP est disponible dans le package android.mtp et fournit les classes suivantes:

  • MtpDevice encapsule un appareil MTP connecté via le bus hôte USB. Une application peut instancier un objet de ce type, puis utiliser ses méthodes pour obtenir des informations sur l'appareil et les objets qui y sont stockés, pour ouvrir la connexion et transférer des données. Voici quelques-unes des méthodes :
    • getObjectHandles() renvoie une liste de handle pour tous les objets de l'appareil qui correspondent à un format et à un parent spécifiés. Pour obtenir des informations sur un objet, une application peut transmettre un handle à getObjectInfo().
    • importFile() permet à une application de copier les données d'un objet dans un fichier de stockage externe. Cet appel peut être bloqué pendant une durée arbitraire en fonction de la taille des données et de la vitesse des appareils. Il doit donc être effectué à partir d'un thread spécifique.
    • open() permet à une application d'ouvrir un appareil MTP/PTP connecté.
    • getThumbnail() renvoie la vignette de l'objet sous forme de tableau d'octets.
  • MtpStorageInfo contient des informations sur une unité de stockage sur un appareil MTP, correspondant à l'ensemble de données StorageInfo décrit dans la section 5.2.2 de la spécification MTP. Les méthodes de la classe permettent à une application d'obtenir la chaîne de description, l'espace disponible, la capacité de stockage maximale, l'ID de stockage et l'identifiant de volume d'une unité de stockage.
  • MtpDeviceInfo contient des informations sur un appareil MTP correspondant à l'ensemble de données DeviceInfo décrit dans la section 5.1.1 de la spécification MTP. Les méthodes de cette classe permettent aux applications d'obtenir le fabricant, le modèle, le numéro de série et la version d'un appareil.
  • MtpObjectInfo contient des informations sur un objet stocké sur un appareil MTP, correspondant à l'ensemble de données ObjectInfo décrit dans la section 5.3.1 de la spécification MTP. Les méthodes de la classe permettent aux applications d'obtenir la taille, le format de données, le type d'association, la date de création et les informations de la vignette d'un objet.
  • MtpConstants fournit des constantes pour déclarer les codes de format de fichier MTP, le type d'association et l'état de protection.

Prise en charge des nouveaux périphériques d'entrée et événements de mouvement

Android 3.1 étend le sous-système d'entrée pour prendre en charge de nouveaux périphériques d'entrée et de nouveaux types d'événements de mouvement, sur toutes les vues et fenêtres. Les développeurs peuvent s'appuyer sur ces fonctionnalités pour permettre aux utilisateurs d'interagir avec leurs applications à l'aide de souris, de trackballs, de joysticks, de manettes de jeu et d'autres appareils, en plus des claviers et des écrans tactiles.

Pour la gestion des entrées avec la souris, la molette et le trackball, la plate-forme accepte deux nouvelles actions d'événements de mouvement:

  • ACTION_SCROLL, qui décrit l'emplacement du pointeur où un mouvement de défilement non tactile s'est produit, par exemple à partir de la molette de la souris. Dans MotionEvent, la valeur des axes AXIS_HSCROLL et AXIS_VSCROLL spécifie le mouvement de défilement relatif.
  • ACTION_HOVER_MOVE indique la position actuelle de la souris lorsque vous n'appuyez sur aucun bouton, ainsi que les points intermédiaires depuis le dernier événement HOVER_MOVE. Les notifications d'entrée et de sortie au passage de la souris ne sont pas encore prises en charge.

Pour prendre en charge les joysticks et les manettes de jeu, la classe InputDevice inclut les nouvelles sources de périphérique d'entrée suivantes:

Pour décrire les événements de mouvement provenant de ces nouvelles sources, ainsi que ceux provenant de souris et de trackballs, la plate-forme définit désormais les codes d'axe sur MotionEvent, de la même manière qu'elle définit les codes de touche sur KeyEvent. Les nouveaux codes d'axe des joysticks et des manettes de jeu incluent AXIS_HAT_X, AXIS_HAT_Y, AXIS_RTRIGGER, AXIS_ORIENTATION, AXIS_THROTTLE et bien d'autres. Les axes MotionEvent existants sont représentés par AXIS_X, AXIS_Y, AXIS_PRESSURE, AXIS_SIZE, AXIS_TOUCH_MAJOR, AXIS_TOUCH_MINOR, AXIS_TOOL_MAJOR, AXIS_TOOL_MINOR et AXIS_ORIENTATION.

En outre, MotionEvent définit un certain nombre de codes d'axe génériques utilisés lorsque le framework ne sait pas comment mapper un axe particulier. Des appareils spécifiques peuvent utiliser les codes d'axe génériques pour transmettre des données de mouvement personnalisées aux applications. Pour obtenir la liste complète des axes et de leurs interprétations, consultez la documentation de la classe MotionEvent.

La plate-forme fournit aux applications des événements de mouvement par lots. Un même événement peut donc contenir une position actuelle et plusieurs "mouvements historiques". Les applications doivent utiliser getHistorySize() pour obtenir le nombre d'échantillons historiques, puis récupérer et traiter tous les échantillons historiques dans l'ordre à l'aide de getHistoricalAxisValue(). Les applications doivent ensuite traiter l'exemple actuel à l'aide de getAxisValue().

Certains axes peuvent être récupérés à l'aide de méthodes d'accesseur spéciales. Par exemple, au lieu d'appeler getAxisValue(), les applications peuvent appeler getX(). Les axes avec des accesseurs intégrés sont AXIS_X, AXIS_Y, AXIS_PRESSURE, AXIS_SIZE, AXIS_TOUCH_MAJOR, AXIS_TOUCH_MINOR, AXIS_TOOL_MAJOR, AXIS_TOOL_MINOR et AXIS_ORIENTATION.

Chaque périphérique d'entrée possède un ID unique attribué par le système et peut également fournir plusieurs sources. Lorsqu'un appareil fournit plusieurs sources, plusieurs sources peuvent fournir des données d'axe à l'aide du même axe. Par exemple, un événement tactile provenant de la source tactile utilise l'axe X pour les données de position de l'écran, tandis qu'un événement tactile provenant de la source du joystick utilise l'axe X pour la position du joystick à la place. C'est pourquoi il est important que les applications interprètent les valeurs des axes en fonction de la source d'où elles proviennent. Lors de la gestion d'un événement de mouvement, les applications doivent utiliser des méthodes de la classe InputDevice pour déterminer les axes compatibles avec un appareil ou une source. Plus précisément, les applications peuvent utiliser getMotionRanges() pour interroger tous les axes d'un appareil ou tous les axes d'une source donnée de l'appareil. Dans les deux cas, les informations de plage des axes renvoyés dans l'objet InputDevice.MotionRange spécifient la source de chaque valeur d'axe.

Enfin, comme les événements de mouvement des joysticks, des manettes de jeu, des souris et des trackballs ne sont pas des événements tactiles, la plate-forme ajoute une nouvelle méthode de rappel pour les transmettre à un View en tant qu'événements de mouvement "génériques". Plus précisément, il signale les événements de mouvement non tactile aux View via un appel à onGenericMotionEvent() plutôt qu'à onTouchEvent().

La plate-forme envoie les événements de mouvement génériques différemment, en fonction de la classe de la source de l'événement. Les événements SOURCE_CLASS_POINTER sont dirigés vers View sous le pointeur, de la même manière que les événements tactiles fonctionnent. Tous les autres accèdent au View actuellement sélectionné. Par exemple, cela signifie qu'un View doit être sélectionné pour recevoir des événements liés au joystick. Si nécessaire, les applications peuvent gérer ces événements au niveau de l'activité ou de la boîte de dialogue en y implémentant onGenericMotionEvent() à la place.

Pour examiner un exemple d'application qui utilise des événements de mouvement du joystick, consultez GameControllerInput et GameView.

API RTP

Android 3.1 expose une API à sa pile RTP (Real-time Transport Protocol) intégrée, que les applications peuvent utiliser pour gérer le flux de données interactif ou à la demande. En particulier, les applications qui proposent des fonctionnalités de VoIP, de push pour discuter, de conférence et de streaming audio peuvent utiliser l'API pour lancer des sessions et transmettre ou recevoir des flux de données sur n'importe quel réseau disponible.

L'API RTP est disponible dans le package android.net.rtp. Les classes incluent:

  • RtpStream, la classe de base des flux qui envoient et reçoivent des paquets réseau avec des charges utiles multimédias via RTP.
  • AudioStream, une sous-classe de RtpStream qui contient des charges utiles audio via RTP.
  • AudioGroup, un hub audio local permettant de gérer et de mixer le haut-parleur de l'appareil, le micro et le AudioStream.
  • AudioCodec, qui contient un ensemble de codecs que vous définissez pour un AudioStream.

Pour prendre en charge l'audioconférence et des utilisations similaires, une application instancie deux classes en tant que points de terminaison du flux:

  • AudioStream spécifie un point de terminaison distant, et consiste en un mappage de réseau et un AudioCodec configuré.
  • AudioGroup représente le point de terminaison local pour une ou plusieurs AudioStreams. Le AudioGroup mélange tous les AudioStream et interagit éventuellement avec le haut-parleur de l'appareil et le micro en même temps.

La méthode la plus simple implique l'utilisation d'un seul point de terminaison distant et d'un point de terminaison local. Pour les utilisations plus complexes, veuillez vous reporter aux limites décrites pour AudioGroup.

Pour utiliser l'API RTP, les applications doivent demander l'autorisation de l'utilisateur en déclarant <uses-permission android:name="android.permission.INTERNET"> dans leurs fichiers manifestes. Pour obtenir le micro de l'appareil, l'autorisation <uses-permission android:name="android.permission.RECORD_AUDIO"> est également requise.

Widgets d'application redimensionnables

À partir d'Android 3.1, les développeurs peuvent redimensionner leurs widgets d'écran d'accueil, horizontalement, verticalement ou sur les deux axes. Les utilisateurs appuyez de manière prolongée sur un widget pour afficher ses poignées de redimensionnement, puis faites glisser les poignées horizontales et/ou verticales pour modifier la taille sur la grille de mise en page.

Les développeurs peuvent rendre n'importe quel widget de l'écran d'accueil redimensionnable en définissant un attribut resizeMode dans les métadonnées AppWidgetProviderInfo du widget. Les valeurs de l'attribut resizeMode incluent "horizontal", "vertical" et "none". Pour déclarer un widget comme redimensionnable horizontalement et verticalement, indiquez la valeur "horizontal|vertical".

Exemple : 

<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
    android:minWidth="294dp"
    android:minHeight="72dp"
    android:updatePeriodMillis="86400000"
    android:previewImage="@drawable/preview"
    android:initialLayout="@layout/example_appwidget"
    android:configure="com.example.android.ExampleAppWidgetConfigure"
    android:resizeMode="horizontal|vertical" >
</appwidget-provider>

Pour en savoir plus sur les widgets de l'écran d'accueil, consultez la documentation sur les widgets d'application.

Framework d'animation

  • Nouvelle classe ViewPropertyAnimator
    • Une nouvelle classe ViewPropertyAnimator offre aux développeurs un moyen pratique d'animer des propriétés sélectionnées sur des objets View. La classe automatise et optimise l'animation des propriétés, et facilite la gestion de plusieurs animations simultanées sur un objet View.

      L'utilisation de ViewPropertyAnimator est simple. Pour animer les propriétés d'un View, appelez animate() afin de construire un objet ViewPropertyAnimator pour ce View. Utilisez les méthodes sur ViewPropertyAnimator pour spécifier la propriété à animer et le mode d'animation. Par exemple, pour que View devienne transparent, appelez alpha(0);. L'objet ViewPropertyAnimator gère les détails de la configuration et du démarrage de la classe Animator sous-jacente, puis de l'affichage de l'animation.

  • Couleur d'arrière-plan de l'animation
    • Les nouvelles méthodes getBackgroundColor() et setBackgroundColor(int) vous permettent d'obtenir/de définir la couleur d'arrière-plan des animations, uniquement pour les animations de fenêtre. Actuellement, l'arrière-plan doit être noir, avec le niveau alpha souhaité.
  • Récupération de la fraction animée à partir de ViewAnimator
    • Une nouvelle méthode getAnimatedFraction() vous permet d'obtenir la fraction d'animation actuelle (la fraction écoulée/interpolée utilisée dans la dernière mise à jour de l'image) à partir d'un élément ValueAnimator.

Framework d'UI

  • Rendu forcé d'un calque
    • Une nouvelle méthode buildLayer() permet à une application de forcer la création du calque d'une vue, qui s'y affiche immédiatement. Par exemple, une application peut utiliser cette méthode pour afficher une vue dans sa couche avant de lancer une animation. Si la vue est complexe, vous pouvez l'afficher dans le calque avant de démarrer l'animation pour éviter de sauter des images.
  • Distance de la caméra
    • Les applications peuvent utiliser une nouvelle méthode setCameraDistance(float) pour définir la distance entre la caméra et un affichage. Cela permet aux applications de mieux contrôler les transformations 3D de la vue, telles que les rotations.
  • Obtenir une vue de l'agenda à partir d'un sélecteur de date
  • Obtenir des rappels lorsque des vues sont dissociées
  • Écouteur du fil d'Ariane de fragment, nouvelle signature onInflate()
  • Afficher les résultats de recherche dans un nouvel onglet
    • Une clé de données EXTRA_NEW_SEARCH pour les intents ACTION_WEB_SEARCH vous permet d'ouvrir une recherche dans un nouvel onglet du navigateur plutôt que dans un onglet existant.
  • Curseur de texte drawable
    • Vous pouvez maintenant spécifier un drawable à utiliser comme curseur de texte à l'aide du nouvel attribut de ressource textCursorDrawable.
  • Paramètre enfant affiché dans les vues à distance
  • Touches génériques pour manettes de jeu et autres périphériques d'entrée
    • KeyEvent ajoute une gamme de codes de clavier génériques pour accueillir les boutons des manettes de jeu. La classe ajoute également isGamepadButton(int) et plusieurs autres méthodes d'assistance pour utiliser les codes de clavier.

Graphismes

  • Aides pour la gestion des bitmaps
    • setHasAlpha(boolean) permet à une application d'indiquer que tous les pixels d'un bitmap sont connus pour être opaques (faux) ou que certains pixels peuvent contenir des valeurs alpha non opaques (true). Notez que pour certaines configurations (telles que RGB_565), cet appel est ignoré, car il n'accepte pas les valeurs alpha par pixel. Il s'agit d'une indication de dessin, car dans certains cas, un bitmap reconnu opaque peut prendre un cas de dessin plus rapide qu'un bitmap qui peut avoir des valeurs alpha non opaques par pixel.
    • getByteCount() obtient la taille d'un bitmap en octets.
    • getGenerationId() permet à une application de savoir si un bitmap a été modifié, par exemple à des fins de mise en cache.
    • sameAs(android.graphics.Bitmap) détermine si un bitmap donné diffère du bitmap actuel en termes de dimension, de configuration ou de données de pixels.
  • Définir la position et la rotation de l'appareil photo
    • Camera ajoute deux nouvelles méthodes rotate() et setLocation() pour contrôler la position de l'appareil photo et effectuer les transformations 3D.

Réseau

  • Verrouillage Wi-Fi hautes performances
    • Un nouveau verrouillage Wi-Fi hautes performances permet aux applications de maintenir des connexions Wi-Fi hautes performances même lorsque l'écran de l'appareil est éteint. Les applications qui diffusent de la musique, des vidéos ou des voix pendant de longues périodes peuvent obtenir le verrou Wi-Fi hautes performances pour garantir des performances de streaming, même lorsque l'écran est éteint. Comme il consomme plus d'énergie, les applications doivent acquérir le Wi-Fi hautes performances lorsqu'une connexion active de longue durée est nécessaire.

      Pour créer un verrouillage hautes performances, transmettez WIFI_MODE_FULL_HIGH_PERF en tant que mode verrouillé dans un appel à createWifiLock().

  • Plus de statistiques sur le trafic
    • Les applications peuvent désormais accéder aux statistiques sur d'autres types d'utilisation du réseau à l'aide de nouvelles méthodes dans TrafficStats. Les applications peuvent utiliser ces méthodes pour obtenir des statistiques UDP, le nombre de paquets, les octets et les segments de charge utile de transmission/réception TCP pour un UID donné.
  • Nom d'utilisateur pour l'authentification SIP
    • Les applications peuvent désormais obtenir et définir le nom d'utilisateur d'authentification SIP pour un profil à l'aide des nouvelles méthodes getAuthUserName() et setAuthUserName().

Gestionnaire de téléchargement

  • Gestion des téléchargements terminés
    • Les applications peuvent désormais lancer des téléchargements qui n'informent les utilisateurs qu'une fois l'opération terminée. Pour lancer ce type de téléchargement, les applications transmettent VISIBILITY_VISIBLE_NOTIFY_ONLY_COMPLETION dans la méthode setNotificationVisibility() de l'objet de requête.
    • Une nouvelle méthode, addCompletedDownload(), permet à une application d'ajouter un fichier à la base de données des téléchargements afin qu'il puisse être géré par l'application Téléchargements.
  • Afficher les téléchargements triés par taille

Framework IME

  • Obtenir la clé de valeur supplémentaire d'un mode de saisie

Contenus multimédias

  • Nouveaux formats audio en streaming
    • Media Framework ajoute la prise en charge intégrée du contenu ADTS AAC brut pour améliorer le streaming audio, ainsi que la compatibilité avec l'audio FLAC, pour du contenu audio compressé de la plus haute qualité (sans perte). Pour en savoir plus, consultez le document Formats multimédias acceptés.

Lancer les commandes sur les applications arrêtées

À partir d'Android 3.1, le gestionnaire de packages du système assure le suivi des applications à l'état arrêté et permet de contrôler leur lancement à partir des processus en arrière-plan et d'autres applications.

Notez que l'état arrêté d'une application n'est pas le même que celui d'une activité. Le système gère ces deux états d'arrêt séparément.

La plate-forme définit deux nouveaux indicateurs d'intent qui permettent à un expéditeur de spécifier si l'intent doit être autorisé à activer des composants dans une application arrêtée.

Lorsqu'aucune de ces options, ou les deux, n'est définie dans un intent, le comportement par défaut consiste à inclure des filtres d'applications arrêtées dans la liste des cibles potentielles.

Notez que le système ajoute FLAG_EXCLUDE_STOPPED_PACKAGES à tous les intents de diffusion. Cela permet d'éviter que les annonces provenant de services d'arrière-plan ne lancent par inadvertance ou inutilement des composants d'applications arrêtées. Un service ou une application d'arrière-plan peut ignorer ce comportement en ajoutant l'indicateur FLAG_INCLUDE_STOPPED_PACKAGES aux intents de diffusion qui doivent être autorisés à activer des applications arrêtées.

Les applications sont arrêtées lorsqu'elles sont installées pour la première fois, mais qu'elles ne sont pas encore lancées et lorsqu'elles sont manuellement arrêtées par l'utilisateur (dans "Gérer les applications").

Notification du premier lancement et de la première mise à jour de l'application

La plate-forme ajoute une notification améliorée du premier lancement de l'application et des mises à niveau via deux nouvelles actions d'intent:

  • ACTION_PACKAGE_FIRST_LAUNCH : envoyé au package d'installation d'une application lors du premier lancement de celle-ci (c'est-à-dire la première fois qu'elle sort d'un état arrêté). Les données contiennent le nom du package.
  • ACTION_MY_PACKAGE_REPLACED : informe une application qu'elle a été mise à jour et qu'une nouvelle version a été installée par rapport à une version existante. Il n'est envoyé qu'à l'application qui a été remplacée. Il ne contient aucune donnée supplémentaire. Pour le recevoir, déclarez un filtre d'intent pour cette action. Vous pouvez utiliser l'intent pour déclencher du code qui aide votre application à s'exécuter correctement après une mise à niveau.

    Cet intent est envoyé directement à l'application, mais uniquement si celle-ci a été mise à niveau alors qu'elle était démarrée (et non arrêtée).

Principaux utilitaires

  • Cache LRU
    • Une nouvelle classe LruCache permet à vos applications de bénéficier d'une mise en cache efficace. Les applications peuvent l'utiliser pour réduire le temps passé à calculer ou à télécharger des données sur le réseau, tout en conservant une quantité de mémoire raisonnable pour les données mises en cache.LruCache est un cache qui contient des références fortes à un nombre limité de valeurs. Chaque fois qu'une valeur est consultée, elle est déplacée en tête de file d'attente. Lorsqu'une valeur est ajoutée à un cache complet, la valeur à la fin de cette file d'attente est supprimée et peut devenir éligible à la récupération de mémoire.
  • Descripteur de fichier en tant que int

WebKit

  • Cookies de schéma de fichiers
    • CookieManager est désormais compatible avec les cookies qui utilisent le schéma d'URI file:. Vous pouvez utiliser setAcceptFileSchemeCookies() pour activer/désactiver la prise en charge des cookies de schémas de fichiers avant de créer une instance de WebView ou CookieManager. Dans une instance CookieManager, vous pouvez vérifier si les cookies de schémas de fichiers sont activés en appelant allowFileSchemeCookies().
  • Notification de demande de connexion
    • Pour prendre en charge les fonctionnalités de connexion automatique du navigateur introduites dans Android 3.0, la nouvelle méthode onReceivedLoginRequest() informe l'application hôte qu'une requête de connexion automatique a été traitée pour l'utilisateur.
  • Classes et interfaces supprimées
    • Plusieurs classes et interfaces ont été supprimées de l'API publique, alors qu'elles étaient auparavant dans un état obsolète. Pour en savoir plus, consultez le rapport sur les différences entre les API.

Browser

L'application Navigateur ajoute les fonctionnalités suivantes pour prendre en charge les applications Web:

  • Prise en charge de la lecture intégrée des vidéos intégrées à la balise <video> HTML5. La lecture est accélérée par le matériel dans la mesure du possible.
  • Prise en charge des calques pour les éléments à position fixe pour tous les sites (mobile et ordinateur).

Nouvelles constantes de caractéristiques

La plate-forme ajoute de nouvelles constantes de fonctionnalités matérielles que les développeurs peuvent déclarer dans les fichiers manifestes de leur application afin d'informer les entités externes telles que Google Play des exigences de l'application concernant les nouvelles fonctionnalités matérielles compatibles avec cette version de la plate-forme. Les développeurs déclarent ces constantes de fonctionnalités et d'autres dans les éléments du fichier manifeste <uses-feature>.

  • android.hardware.usb.accessory : l'application utilise l'API USB pour communiquer avec les périphériques matériels externes connectés via USB et fonctionner en tant qu'hôtes.
  • android.hardware.usb.host : l'application utilise l'API USB pour communiquer avec les périphériques matériels externes connectés via USB et fonctionner comme des appareils.

Google Play filtre les applications en fonction des fonctionnalités déclarées dans les éléments du fichier manifeste <uses-feature>. Pour en savoir plus sur la déclaration de fonctionnalités dans un fichier manifeste d'application, consultez Filtres Google Play.

Rapport sur les différences entre les API

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

Niveau d'API

La plate-forme Android 3.1 fournit une version mise à jour de l'API du framework. Un identifiant entier (12) est attribué à l'API Android 3.1, 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 3.1 dans votre application, vous devez compiler l'application avec la bibliothèque Android fournie dans la plate-forme SDK Android 3.1. En fonction de vos besoins, vous devrez peut-être également ajouter un attribut android:minSdkVersion="12" à l'élément <uses-sdk> dans le fichier manifeste de l'application.

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