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 n'inclut aucune bibliothèque externe.

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

API USB

Android 3.1 introduit de nouvelles API performantes pour l’intégration de périphériques connectés aux applications exécutées sur la plateforme. Ces API reposent sur une pile USB (Universal Serial Bus) et sur des services intégrés à la plate-forme, y compris la prise en charge de l'hôte et du périphérique USB des interactions. À l'aide des API, les développeurs peuvent créer des applications capables de découvrir, communiquer et gérer divers types d'appareils connectés via USB.

La pile et les API distinguent deux types de matériel USB de base, basés sur si l'appareil Android fait office d'hôte ou de matériel externe est l'hôte:

  • Un périphérique USB est un élément matériel connecté qui dépend du Appareil Android servant d'hôte. Par exemple, la plupart des périphériques d'entrée, des souris, et les joysticks sont des périphériques USB, tout comme de nombreux appareils photo, hubs, etc.
  • Un accessoire USB est un élément matériel connecté doté d'un câble USB le contrôleur hôte, il fournit l'alimentation et est conçu pour communiquer avec Appareils Android via USB. Divers périphériques peuvent se connecter en tant que des contrôleurs robotiques, des équipements musicaux, des vélos d'appartement, et plus encore.

Pour les deux types (périphériques et accessoires USB), la les API USB de la plate-forme prennent en charge la détection par diffusion d'intent lorsqu'elle est connectée ou détachés, ainsi que les interfaces, points de terminaison et modes de transfert standards (contrôle, enregistrement groupé et interruptions).

Les API USB sont disponibles dans le package android.hardware.usb. La la classe centrale est UsbManager, qui fournit des méthodes d’assistance pour identifier et communiquer avec à la fois des périphériques USB et des accessoires USB. Les applications peuvent acquérir une instance UsbManager, puis une requête permettant d'obtenir la liste des appareils ou accessoires, puis communiquer avec eux ou les gérer. UsbManager déclare également les actions d'intent que le des annonces du système, pour annoncer lorsqu'un périphérique ou un accessoire USB est connecté ou détaché.

Les autres cours incluent:

  • UsbDevice, une classe représentant des éléments externes ; du matériel connecté en tant que périphérique USB (le périphérique Android jouant le rôle de l'hôte).
  • UsbAccessory, représentant du matériel externe connecté en tant qu'hôte USB (l'appareil Android faisant office d'hôte USB) appareil).
  • UsbInterface et UsbEndpoint, qui permettent d'accéder à une clé USB standard des interfaces et des points de terminaison d'un appareil.
  • UsbDeviceConnection et UsbRequest, pour l'envoi et la réception de données et le contrôle des messages vers ou depuis un périphérique USB, de manière synchrone et asynchrone.
  • UsbConstants, qui fournit des constantes pour déclarer des types de points de terminaison, des classes d'appareils, etc.

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

De plus, les développeurs peuvent demander un filtrage sur Google Play, afin que leurs applications ne sont pas accessibles aux utilisateurs dont les appareils ne fournissent pas la prise en charge USB appropriée. Pour demander un filtrage, ajoutez l'un des éléments ou les deux ci-dessous au fichier manifeste de l'application, le cas échéant:

  • Si l'application doit être visible uniquement sur les appareils compatibles USB mode hôte (connexion de périphériques USB), déclarez cet élément:

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

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

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

Pour des informations complètes sur le développement d'applications qui interagissent avec Pour les accessoires USB, consultez les documentation pour les développeurs.

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

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 autres appareils PTP. La nouvelle API permet à pour recevoir des notifications lorsque des appareils sont connectés et retirés, gérer les fichiers et le stockage sur ces appareils, et transférer les fichiers et les métadonnées vers et de leur part. L'API MTP implémente 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 ces cours:

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

Compatibilité avec de 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'événements de mouvement, dans toutes les vues et toutes les fenêtres. Les développeurs peuvent s'appuyer ces fonctionnalités pour permettre aux utilisateurs d'interagir avec leurs applications à l'aide de souris, trackballs, joysticks, manettes de jeu et autres appareils, en plus des claviers et des écrans tactiles.

Pour gérer la saisie à la souris, à la molette et au trackball, la plate-forme prend en charge deux nouvelles actions d'événement de mouvement:

  • ACTION_SCROLL, qui décrit le pointeur lieu où un mouvement de défilement non tactile, comme la molette de la souris, s'est déroulée. Dans MotionEvent, la valeur des axes AXIS_HSCROLL et AXIS_VSCROLL spécifie le défilement relatif. du mouvement.
  • ACTION_HOVER_MOVE, indique l'état actuel la position de la souris lorsque vous n'appuyez pas sur des boutons, ainsi que les points depuis le dernier événement HOVER_MOVE. Pointer sur l'entrée et la sortie les notifications ne sont pas encore prises en charge.

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

Décrire les événements de mouvement provenant de ces nouvelles sources, ainsi que ceux provenant de souris et les trackballs, la plate-forme définit désormais les codes des axes sur MotionEvent, de la même manière qu'elle définit les codes clés sur KeyEvent. Nouveaux codes d'axe pour les joysticks et les manettes de jeu comprennent AXIS_HAT_X, AXIS_HAT_Y, AXIS_RTRIGGER, AXIS_ORIENTATION, AXIS_THROTTLE et de nombreux 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.

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

La plate-forme fournit des événements de mouvement aux applications par lots. Ainsi, peut 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 l'ensemble exemples dans l'ordre à l'aide de getHistoricalAxisValue(). Ensuite, les applications doivent traiter la version actuelle exemple avec 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 dotés d'accesseurs intégrés incluent 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 identifiant 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 en utilisant le même axe. Par exemple, un événement tactile de la source tactile utilise l'axe X pour les données de position de l'écran, tandis qu'un joystick provenant de la source du joystick utilise l'axe X pour la position du joystick. à la place. Pour cette raison, il est important que les applications interprètent les axes en fonction de la source. Lors de la gestion d’un mouvement , les applications doivent utiliser des méthodes sur l'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'un appareil donné. source de l'appareil. Dans les deux cas, les informations de portée des axes renvoyées dans L'objet InputDevice.MotionRange spécifie la source chaque valeur d'axe.

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

La plate-forme envoie différemment les événements de mouvement génériques, en fonction de la classe de source d'événement. SOURCE_CLASS_POINTER événements accédez à View sous le pointeur, comme lorsque vous appuyez le fonctionnement des événements. Tous les autres sont placés dans l'élément View actuellement sélectionné. Par exemple, cela signifie qu'un View doit être sélectionné pour recevoir des événements de type joystick. Si nécessaire, les applications peuvent gérer ces événements au niveau niveau "Activity" ou "Dialog" en y implémentant onGenericMotionEvent() à la place.

Pour examiner un exemple d'application qui utilise le mouvement du joystick , consultez la section GameControllerInput. et GameView.

API RTP

Android 3.1 expose une API à son protocole RTP (Real-time Transport Protocol) intégré que les applications peuvent utiliser pour gérer des données interactives ou à la demande le flux de données. En particulier, les applications qui proposent des services VoIP, Push-to-Talk, et le streaming audio peuvent utiliser l'API pour lancer des sessions, et transmettre ou recevoir flux de données sur n'importe quel réseau disponible.

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

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

Pour prendre en charge les conférences audio et les utilisations similaires, une application instancie deux classes comme points de terminaison pour le flux:

  • AudioStream spécifie un point de terminaison distant et se compose du mappage de réseau et un AudioCodec configuré.
  • AudioGroup représente le point de terminaison local AudioStream ou plus. Mix des AudioGroup tous les AudioStream et interagit éventuellement avec l'appareil le haut-parleur et le microphone en même temps.

L'utilisation la plus simple implique un seul point de terminaison distant et un point de terminaison local. Pour les utilisations plus complexes, reportez-vous aux limites décrites pour AudioGroup

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

Widgets d'application redimensionnables

À partir d'Android 3.1, les développeurs peuvent créer des widgets sur leur écran d'accueil. redimensionnables : horizontalement, verticalement ou sur les deux axes. Les utilisateurs appuient de manière prolongée sur un pour afficher les poignées de redimensionnement, puis faites glisser les curseurs poignées pour modifier la taille sur la grille de mise en page.

Les développeurs peuvent redimensionner n'importe quel widget de l'écran d'accueil en définissant un resizeMode dans les métadonnées AppWidgetProviderInfo du widget. Les valeurs de la paire valeur/clé L'attribut resizeMode inclut "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 page Widgets d'application. dans la documentation Google Cloud.

Framework d'animation

  • Nouvelle classe ViewPropertyAnimator <ph type="x-smartling-placeholder">
      </ph>
    • Une nouvelle classe ViewPropertyAnimator fournit pratique moyen pour les développeurs d'animer des propriétés de sélection sur des objets View. La classe automatise et optimise l'animation des propriétés, ce qui facilite gérer plusieurs animations simultanées sur un objet View.

      L'utilisation de ViewPropertyAnimator est simple. Pour animer les propriétés de un View, appelez animate() pour construire un objet ViewPropertyAnimator pour ce View. Utilisez les sur l'ViewPropertyAnimator pour spécifier la propriété à et comment l'animer. Par exemple, pour passer le View en fondu transparent, procédez comme suit : appelez alpha(0);. L'objet ViewPropertyAnimator gère les détails de la configuration de la classe Animator sous-jacente, de son démarrage, puis de l'affichage de la classe de l'animation.

  • Couleur d'arrière-plan de l'animation <ph type="x-smartling-placeholder">
      </ph>
    • Nouveaux getBackgroundColor() et Les méthodes setBackgroundColor(int) permettent vous permet d'obtenir/définir la couleur d'arrière-plan des animations, pour les animations de fenêtre. uniquement. Actuellement, l'arrière-plan doit être noir, avec le niveau alpha souhaité.
  • Obtenir la fraction animée de ViewAnimator <ph type="x-smartling-placeholder">
      </ph>
    • Un nouveau getAnimatedFraction() méthode vous permet d'obtenir la fraction actuelle de l'animation, c'est-à-dire le temps écoulé/interpolé fraction utilisée dans la dernière mise à jour de frames (à partir d'un ValueAnimator).

Framework d'UI

  • Rendu forcé d'un calque <ph type="x-smartling-placeholder">
      </ph>
    • Une nouvelle méthode buildLayer() permet à une application forcer la création du calque d'une vue et l'affichage immédiat de la vue dans celui-ci. Par exemple, une application peut utiliser cette méthode pour afficher une vue dans son avant de lancer une animation. Si la vue est complexe, le rendu le calque avant de lancer l'animation permet d'éviter de sauter des images.
  • Distance de la caméra <ph type="x-smartling-placeholder">
      </ph>
    • Les applications peuvent utiliser une nouvelle méthode setCameraDistance(float) pour définir la distance par rapport à appareil photo à une vue. Les applications peuvent ainsi mieux contrôler les transformations 3D des la vue, comme les rotations.
  • Obtention d'une vue du calendrier à l'aide du sélecteur de date <ph type="x-smartling-placeholder">
  • Obtenir des rappels lorsque des vues sont dissociées <ph type="x-smartling-placeholder">
  • Écouteur du fil d'Ariane des fragments, nouvelle signature onInflate() <ph type="x-smartling-placeholder">
  • Afficher les résultats de recherche dans un nouvel onglet <ph type="x-smartling-placeholder">
      </ph>
    • Une clé de données EXTRA_NEW_SEARCH pour les intents ACTION_WEB_SEARCH vous permet d'ouvrir une recherche dans un dans un nouvel onglet du navigateur plutôt que dans un onglet existant.
  • Curseur de texte drawable <ph type="x-smartling-placeholder">
      </ph>
    • Vous pouvez désormais spécifier un drawable à utiliser comme curseur de texte à l'aide de la nouvelle l'attribut de ressource textCursorDrawable.
  • Paramètre enfant affiché dans les vues à distance <ph type="x-smartling-placeholder">
  • Touches génériques pour manettes de jeu et autres périphériques d'entrée <ph type="x-smartling-placeholder">
      </ph>
    • KeyEvent ajoute une plage 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 travailler avec des codes de clavier.

Graphiques

  • Outils d'aide pour la gestion des bitmaps <ph type="x-smartling-placeholder">
      </ph>
    • setHasAlpha(boolean) permet à une application d'indiquer que tous les pixels d'un bitmap sont connus pour être opaques (faux) ou que certains des peuvent contenir des valeurs alpha non opaques (vrai). Notez que pour certaines configurations (telles que RGB_565, par exemple), cet appel est ignoré, car il n'est pas compatible avec la valeur alpha par pixel. valeurs. Il s'agit d'une indication de dessin, comme dans certains cas, un bitmap connu peut prendre un cas de dessin plus rapide qu'un cas de dessin non opaque. les valeurs alpha par pixel.
    • getByteCount() obtient la taille d'un bitmap dans octets.
    • getGenerationId() permet à une application pour savoir si un bitmap a été modifié, par exemple pour la mise en cache.
    • sameAs(android.graphics.Bitmap) détermine si un bitmap donné diffère du bitmap actuel, en dimension de configuration ou de données de pixels.
  • Définir l'emplacement et la rotation de la caméra <ph type="x-smartling-placeholder">
      </ph>
    • Camera ajoute deux nouvelles méthodes, rotate() et setLocation(), pour le contrôle le lieu de prise de vue pour les transformations 3D.

Réseau

  • Verrouillage Wi-Fi hautes performances <ph type="x-smartling-placeholder">
      </ph>
    • Un nouveau système de verrouillage Wi-Fi hautes performances permet aux applications 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 Verrouillage Wi-Fi hautes performances pour garantir des performances de streaming même lorsque l'écran est désactivé. Étant donné qu'elle consomme plus d'énergie, les applications doivent acquérir le un réseau Wi-Fi performant lorsqu'un réseau Wi-Fi actif de longue durée est nécessaire .

      Pour créer un verrouillage hautes performances, transmettez WIFI_MODE_FULL_HIGH_PERF comme mode verrouillé dans un à createWifiLock().

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

Gestionnaire de téléchargement

  • Gérer les téléchargements terminés <ph type="x-smartling-placeholder">
      </ph>
    • Les applications peuvent désormais lancer des téléchargements et notifier les utilisateurs uniquement l'achèvement. Pour lancer ce type de téléchargement, les applications transmettront VISIBILITY_VISIBLE_NOTIFY_ONLY_COMPLETION dans la méthode setNotificationVisibility() l'objet de la requête.
    • Une nouvelle méthode, addCompletedDownload(), permet à une application d'ajouter un fichier au de la base de données des téléchargements, de sorte qu'elle puisse être gérée par l'application Téléchargements.
  • Afficher les téléchargements triés par taille <ph type="x-smartling-placeholder">

Framework IME

  • Obtenir la clé de valeur supplémentaire d'un mode de saisie <ph type="x-smartling-placeholder">

Contenus multimédias

  • Nouveaux formats de streaming audio <ph type="x-smartling-placeholder">
      </ph>
    • Le framework multimédia prend en charge le contenu AAC brut d'ADTS AAC, par exemple Streaming audio amélioré, compatibilité avec les fichiers audio FLAC, pour une qualité optimale (sans perte) de contenu audio compressé. Consultez la liste des formats multimédias acceptés. pour en savoir plus.

Commandes de lancement sur arrêtées applications

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

Notez que l'état d'arrêt d'une application n'est pas le même que celui d'une activité à l'état "Arrêté". 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 si l'intent doit être autorisé à activer les composants dans les environnements application.

Si aucun de ces indicateurs ou les deux n'est défini dans un intent, consiste à inclure les filtres des applications arrêtées dans la liste des des cibles potentielles.

Notez que le système ajoute FLAG_EXCLUDE_STOPPED_PACKAGES à toutes les diffusions. intents. Cela permet d'empêcher les diffusions des services d'arrière-plan qui 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 le Indicateur FLAG_INCLUDE_STOPPED_PACKAGES à diffuser des intents qui doivent être autorisés à activer des applications arrêtées.

Les applications sont arrêtées lors de leur première installation, mais elles ne sont pas lancées et quand elles sont arrêtées manuellement par l'utilisateur (dans la section Applications).

Notification du premier lancement et de la mise à niveau de l'application

La plate-forme améliore les notifications lors du premier lancement de l'application et grâce à deux nouvelles actions d'intent:

  • ACTION_PACKAGE_FIRST_LAUNCH — Envoyé à le package d'installation d'une application lorsque celle-ci est lancée pour la première fois ; (c'est-à-dire la première fois qu'il est arrêté). Les données contient le nom du package.
  • ACTION_MY_PACKAGE_REPLACED – Notifie une application sur laquelle elle a été mise à jour, avec une nouvelle version installée 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 vous aide à obtenir l'application fonctionne de nouveau correctement après une mise à niveau.

    Cet intent est envoyé directement à l'application, mais uniquement si l'application a été mis à niveau alors qu'il était en cours de démarrage (et non à l'état "arrêté").

Utilitaires de base

  • Cache LRU <ph type="x-smartling-placeholder">
      </ph>
    • Une nouvelle classe LruCache permet à vos applications de bénéficier grâce à une mise en cache efficace. Les applications peuvent utiliser la classe pour réduire le temps passé de calcul ou de téléchargement de données à partir du réseau, tout en conservant pour les données mises en cache.LruCache est un cache contenant des références fortes à un nombre limité de valeurs. Chaque fois qu'une valeur est si un utilisateur y accède, il est placé en tête de file d'attente. Lorsqu'une valeur est ajoutée à un cache, 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 <ph type="x-smartling-placeholder">

WebKit

  • Cookies de schéma de fichier <ph type="x-smartling-placeholder">
      </ph>
    • Le CookieManager prend désormais en charge les cookies qui utilisent la Schéma d'URI file:. Vous pouvez utiliser setAcceptFileSchemeCookies() pour activer/désactiver la prise en charge des cookies de schéma de fichiers avant de créer une instance. de WebView ou CookieManager. Dans un CookieManager, vous pouvez vérifier si les cookies du schéma de fichiers est activé en appelant allowFileSchemeCookies().
  • Notification de demande de connexion <ph type="x-smartling-placeholder">
      </ph>
    • Pour prendre en charge les fonctionnalités de connexion automatique du navigateur introduites dans Android 3.0, le nouveau Méthode onReceivedLoginRequest() avertit l'hôte application qu'une demande de connexion automatique a été traitée pour l'utilisateur.
  • Classes et interfaces supprimées <ph type="x-smartling-placeholder">
      </ph>
    • Plusieurs classes et interfaces ont été supprimées de l'API publique, après auparavant à l'état "obsolète". Voir l'API rapport sur les différences.

Navigateur

L'application Navigateur ajoute les fonctionnalités suivantes pour assurer la compatibilité applications:

  • Compatibilité avec la lecture intégrée des vidéos intégrées au format HTML5 Balise <video>. Dans la mesure du possible, la lecture est accélérée par le matériel.
  • Prise en charge des couches pour les éléments de 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 leurs fichiers manifestes d'application, afin d'informer les entités externes telles que Google Jeu des exigences de l'application concernant la prise en charge de nouvelles capacités matérielles dans cette version de la plate-forme. Les développeurs déclarent ces fonctionnalités et d'autres constantes dans les éléments du fichier manifeste <uses-feature>.

  • android.hardware.usb.accessory : l'application utilise la clé USB API pour communiquer avec les périphériques matériels externes connectés via USB et fonctionnent comme des hôtes.
  • android.hardware.usb.host : l'application utilise l'API USB. de communiquer avec les périphériques matériels externes connectés via USB et fonctionner comme 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 déclarant des fonctionnalités dans le fichier manifeste d'une application, consultez la page Google Play Filtres.

Rapport sur les différences de l'API

Pour obtenir une vue détaillée de toutes les modifications apportées aux API dans Android 3.1 (API, Niveau 12), consultez la page API rapport sur les différences.

Niveau d'API

La plate-forme Android 3.1 propose une version mise à jour de l'API du framework. L'API Android 3.1 se voit attribuer un identifiant sous forme de nombre entier, 12, soit stockées 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 3.1 dans votre application, vous devez compiler l'application avec la bibliothèque Android fournie dans la plate-forme SDK Android 3.1. Selon vos besoins, vous pourrait devez également ajouter un android:minSdkVersion="12" à l'élément <uses-sdk> dans le fichier fichier manifeste.

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