API Android 3.2

Niveau d'API: 13

Android 3.2 (HONEYCOMB_MR2) est une version incrémentielle de la plate-forme qui ajoute de nouvelles fonctionnalités pour les utilisateurs et les développeurs. Les sections ci-dessous présentent les nouvelles fonctionnalités et les API pour les développeurs.

Pour les développeurs, la plate-forme Android 3.2 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 avec Android 3.2, utilisez Android SDK Manager pour télécharger la plate-forme dans votre SDK.

Points forts de la plate-forme

Nouvelles fonctionnalités utilisateur

  • Optimisations pour une gamme plus large de tablettes

    Android 3.2 inclut diverses optimisations dans le système pour garantir une expérience utilisateur optimale sur une plus large gamme de tablettes.

  • Zoom de compatibilité pour les applications de taille fixe

    Android 3.2 introduit un nouveau mode de zoom de compatibilité qui offre aux utilisateurs une nouvelle façon d'afficher des applications de taille fixe sur des appareils plus grands. Le nouveau mode offre une alternative à l'étirement de l'UI standard pour les applications qui ne sont pas conçues pour s'exécuter sur des écrans plus grands, comme les tablettes. Pour les applications nécessitant une compatibilité, les utilisateurs peuvent accéder à ce nouveau mode depuis une icône de menu dans la barre système.

  • Synchronisation des contenus multimédias à partir d'une carte SD

    Sur les appareils compatibles avec une carte SD, les utilisateurs peuvent désormais charger des fichiers multimédias directement depuis la carte SD vers les applications qui les utilisent. Un service système rend les fichiers accessibles aux applications à partir du Media Store du système.

Nouvelles fonctionnalités pour les développeurs

  • API étendue pour la gestion de la compatibilité des écrans

    Android 3.2 introduit des extensions à l'API de compatibilité d'écran de la plate-forme pour offrir aux développeurs d'autres moyens de gérer l'UI de l'application sur toute la gamme d'appareils Android. L'API inclut de nouveaux qualificatifs de ressources et de nouveaux attributs de fichier manifeste qui vous permettent de contrôler plus précisément la façon dont vos applications s'affichent dans différentes tailles, plutôt que de vous appuyer sur des catégories de tailles généralisées.

    Pour garantir un affichage optimal pour les applications de taille fixe et les applications avec une compatibilité limitée avec différentes tailles d'écran, la plate-forme fournit également un nouveau mode de compatibilité avec le zoom qui affiche l'interface utilisateur sur une zone d'écran plus petite, puis l'agrandit pour remplir l'espace disponible à l'écran. Pour en savoir plus sur l'API d'assistance à l'écran et les commandes qu'elle fournit, consultez les sections ci-dessous.

Présentation de l'API

API d'assistance pour les écrans

Android 3.2 introduit de nouvelles API de prise en charge des écrans qui vous permettent de mieux contrôler l'affichage de vos applications sur différentes tailles d'écran. L'API s'appuie sur l'API de compatibilité avec les écrans existante, y compris le modèle de densité d'écran généralisé de la plate-forme, mais l'étend en lui permettant de cibler précisément des plages d'écran spécifiques en fonction de leurs dimensions, mesurées en unités de pixels indépendantes de la densité (par exemple, 600 dp ou 720 dp de large), plutôt qu'en fonction de leurs tailles d'écran généralisées (par exemple, "large" ou "très grand").

Lorsque vous concevez l'interface utilisateur d'une application, vous pouvez toujours vous appuyer sur la plate-forme pour fournir une abstraction de densité, ce qui signifie que les applications n'ont pas besoin de compenser les différences de densité de pixels réelles entre les appareils. Vous pouvez concevoir l'interface utilisateur de l'application en fonction de l'espace horizontal ou vertical disponible. La plate-forme exprime la quantité d'espace disponible à l'aide de trois nouvelles caractéristiques: smallestWidth, width et height.

  • La smallestWidth d'un écran correspond à sa taille minimale fondamentale, mesurée en pixels indépendants de la densité ("dp"). De la hauteur ou de la largeur de l'écran, c'est la plus courte des deux. Pour un écran en mode portrait, la valeur smallestWidth est normalement basée sur sa largeur, tandis qu'en mode paysage, elle est basée sur sa hauteur. Dans tous les cas, la valeur smallestWidth est dérivée d'une caractéristique fixe de l'écran et ne change pas, quelle que soit l'orientation. La valeur smallestWidth est importante pour les applications, car elle représente la largeur la plus courte possible dans laquelle l'UI de l'application doit être dessinée, sans inclure les zones d'écran réservées par le système.
  • En revanche, la largeur et la hauteur d'un écran représentent l'espace horizontal ou vertical actuellement disponible pour la mise en page de l'application, mesuré en dp, à l'exclusion des zones d'écran réservées par le système. La largeur et la hauteur d'un écran changent lorsque l'utilisateur passe du mode paysage au mode portrait, et vice versa.

L'API de prise en charge des nouveaux écrans est conçue pour vous permettre de gérer l'UI de l'application en fonction de la valeur smallestWidth de l'écran actuel. Si nécessaire, vous pouvez également gérer l'interface utilisateur en fonction de la largeur ou de la hauteur actuelles. À ces fins, l'API fournit les outils suivants:

  • De nouveaux qualificatifs de ressources permettent de cibler les mises en page et d'autres ressources avec une largeur minimale, une largeur ou une hauteur minimales.
  • Nouveaux attributs de fichier manifeste, permettant de spécifier la plage de compatibilité d'écran maximale de l'application

De plus, les applications peuvent toujours interroger le système et gérer le chargement de l'UI et des ressources au moment de l'exécution, comme dans les versions précédentes de la plate-forme.

Étant donné que la nouvelle API vous permet de cibler les écrans plus directement via smallestWidth, la largeur et la hauteur, il est utile de comprendre les caractéristiques types des différents types d'écrans. Le tableau ci-dessous fournit quelques exemples, mesurés en unités "dp".

Tableau 1. Appareils standards, avec densité et taille en dp.

Type Densité (généralisée) Dimensions (dp) smallestWidth (dp)
Téléphone de référence mdpi 320 x 480 320
Petite tablette/Grand téléphone mdpi 480 x 800 480
Tablette 7 pouces mdpi 600 x 1 024 600
Tablette 10 pouces mdpi 800x1280 800

Les sections ci-dessous fournissent plus d'informations sur les nouveaux qualificatifs d'écran et attributs du fichier manifeste. Pour obtenir des informations complètes sur l'utilisation de l'API Screen Support, consultez la page Compatibilité avec plusieurs écrans.

Nouveaux qualificatifs de ressources pour la compatibilité avec les écrans

Les nouveaux qualificatifs de ressources d'Android 3.2 vous permettent de mieux cibler vos mises en page pour des plages de tailles d'écran. À l'aide des qualificatifs, vous pouvez créer des configurations de ressources conçues pour une largeur minimale, une largeur ou une hauteur actuelles minimales spécifiques, mesurées en pixels indépendants de la densité.

Les nouveaux qualificatifs sont les suivants:

  • swNNNdp : spécifie la valeur minimale de smallestWidth sur laquelle la ressource doit être utilisée, mesurée en unités "dp". Comme indiqué ci-dessus, la valeur smallestWidth d'un écran est constante, quelle que soit l'orientation. Exemples : sw320dp, sw720dp, sw720dp.
  • wNNNdp et hNNNdp : spécifie la largeur ou la hauteur minimale à laquelle la ressource doit être utilisée, mesurée en unités "dp". Comme indiqué ci-dessus, la largeur et la hauteur d'un écran dépendent de l'orientation de l'écran et changent à chaque changement d'orientation. Exemples : w320dp, w720dp, h1024dp.

Si nécessaire, vous pouvez également créer plusieurs configurations de ressources qui se chevauchent. Par exemple, vous pouvez taguer certaines ressources pour les utiliser sur tous les écrans de plus de 480 dp, d'autres pour les écrans de plus de 600 dp et d'autres pour les écrans de plus de 720 dp. Lorsque plusieurs configurations de ressources sont qualifiées pour un écran donné, le système sélectionne la configuration la plus proche. Pour contrôler précisément les ressources chargées sur un écran donné, vous pouvez taguer les ressources avec un seul qualificatif ou combiner plusieurs nouveaux ou existants.

Voici quelques exemples d'utilisation des nouveaux qualificatifs en fonction des dimensions typiques listées précédemment:

res/layout/main_activity.xml   # For phones
res/layout-sw600dp/main_activity.xml   # For 7” tablets
res/layout-sw720dp/main_activity.xml   # For 10” tablets
res/layout-w600dp/main_activity.xml   # Multi-pane when enough width
res/layout-sw600dp-w720dp/main_activity.xml   # For large width

Les anciennes versions de la plate-forme ignoreront les nouveaux qualificatifs. Vous pouvez donc les mélanger si nécessaire pour vous assurer que votre application s'affiche correctement sur n'importe quel appareil. Voici quelques exemples:

res/layout/main_activity.xml   # For phones
res/layout-xlarge/main_activity.xml   # For pre-3.2 tablets
res/layout-sw600dp/main_activity.xml   # For 3.2 and up tablets

Pour en savoir plus sur l'utilisation des nouveaux qualificatifs, consultez la section Utiliser de nouveaux qualificatifs de taille.

Nouveaux attributs de fichier manifeste pour la compatibilité avec différentes tailles d'écran

Le framework propose un nouvel ensemble d'attributs de fichier manifeste <supports-screens> qui vous permet de gérer la compatibilité de votre application avec différentes tailles d'écran. Plus précisément, vous pouvez spécifier les plus grands et les plus petits écrans sur lesquels votre application est conçue pour s'exécuter, ainsi que le plus grand écran sur lequel elle est conçue pour s'exécuter sans avoir besoin du nouveau mode de compatibilité de l'écran du système. Comme les qualificateurs de ressources décrits ci-dessus, les nouveaux attributs de fichier manifeste spécifient la plage d'écrans compatibles avec l'application, comme indiqué par smallestWidth.

Voici les nouveaux attributs de fichier manifeste pour la compatibilité avec les écrans:

  • android:compatibleWidthLimitDp="numDp" : cet attribut vous permet de spécifier la plus petite largeur maximale sur laquelle l'application peut s'exécuter sans avoir besoin du mode de compatibilité. Si l'écran actuel est plus grand que la valeur spécifiée, le système affiche l'application en mode normal, mais permet à l'utilisateur de passer au mode de compatibilité via un paramètre dans la barre système.
  • android:largestWidthLimitDp="numDp" : cet attribut vous permet de spécifier la largeur maximale de smallestWidth sur laquelle l'application est conçue pour s'exécuter. Si l'écran actuel est plus grand que la valeur spécifiée, le système force l'application à passer en mode de compatibilité de l'écran pour garantir un affichage optimal sur l'écran actuel.
  • android:requiresSmallestWidthDp="numDp" : cet attribut vous permet de spécifier la largeur minimale la plus petite sur laquelle l'application peut s'exécuter. Si la taille de l'écran actuel est inférieure à la valeur spécifiée, le système considère l'application comme incompatible avec l'appareil, mais n'empêche pas son installation et son exécution.

Remarque:Google Play ne filtre actuellement pas les applications en fonction de l'un des attributs ci-dessus. La prise en charge du filtrage sera ajoutée dans une prochaine version de la plate-forme. Les applications qui nécessitent un filtrage en fonction de la taille de l'écran peuvent utiliser les attributs <supports-screens> existants.

Pour obtenir des informations complètes sur l'utilisation des nouveaux attributs, consultez la section Déclarer la prise en charge des tailles d'écran.

Mode de compatibilité de l'écran

Android 3.2 fournit un nouveau mode de compatibilité de l'écran pour les applications qui déclarent explicitement qu'elles ne sont pas compatibles avec les écrans aussi grands que celui sur lequel elles s'exécutent. Ce nouveau mode "zoom" est mis à l'échelle en pixels. Il affiche l'application dans une zone d'écran plus petite, puis met à l'échelle les pixels pour remplir l'écran actuel.

Par défaut, le système propose le mode de compatibilité de l'écran en tant qu'option utilisateur pour les applications qui en ont besoin. Les utilisateurs peuvent activer et désactiver le mode zoom à l'aide d'une commande disponible dans la barre système.

Étant donné que le nouveau mode de compatibilité de l'écran n'est pas forcément adapté à toutes les applications, la plate-forme permet à l'application de le désactiver à l'aide d'attributs de fichier manifeste. Lorsqu'elle est désactivée par l'application, le système ne propose pas le mode de compatibilité "zoom" aux utilisateurs lorsque l'application est en cours d'exécution.

Remarque:Pour en savoir plus sur le contrôle du mode de compatibilité dans vos applications, consultez l'article Nouveau mode pour les applications sur les grands écrans sur le blog des développeurs Android.

Nouvelle densité d'écran pour les téléviseurs 720p et les appareils similaires

Pour répondre aux besoins des applications exécutées sur les téléviseurs 720p ou similaires avec des écrans à densité modérée, Android 3.2 introduit une nouvelle densité généralisée, tvdpi, avec un ppp d'environ 213. Les applications peuvent interroger la nouvelle densité dans densityDpi et utiliser le nouveau qualificatif tvdpi pour taguer les ressources pour les téléviseurs et les appareils similaires. Exemple :

res/drawable-tvdpi/my_icon.png   # Bitmap for tv density

En règle générale, les applications ne doivent pas avoir besoin de travailler avec cette densité. Dans les cas où une sortie est nécessaire pour un écran 720p, les éléments d'interface utilisateur peuvent être mis à l'échelle automatiquement par la plate-forme.

Framework d'UI

  • Fragments
    • La nouvelle classe Fragment.SavedState contient les informations d'état récupérées à partir d'une instance de fragment via saveFragmentInstanceState().
    • La nouvelle méthode saveFragmentInstanceState() enregistre l'état d'instance actuel du fragment donné. L'état peut être utilisé ultérieurement lors de la création d'une instance du fragment correspondant à l'état actuel.
    • La nouvelle méthode setInitialSavedState() définit l'état enregistré initial d'un fragment lors de sa première création.
    • La nouvelle méthode de rappel onViewCreated() informe le fragment que onCreateView() est revenu, mais avant qu'un état enregistré ne soit restauré dans la vue.
    • La méthode isDetached() détermine si le fragment a été explicitement dissocié de l'UI.
    • Les nouvelles méthodes attach() et detach() permettent à une application de réassocier ou de dissocier des fragments dans l'UI.
    • Une nouvelle méthode de surcharge setCustomAnimations() vous permet de définir des ressources d'animation spécifiques à exécuter pour les opérations d'entrée/de sortie, et en particulier lorsque vous ouvrez la pile "Retour". L'implémentation existante ne tient pas compte du comportement différent des fragments lors de l'affichage de la pile "Retour".
  • Informations sur la taille de l'écran dans ActivityInfo et ApplicationInfo
  • Fonctions d'assistance pour obtenir la taille d'affichage à partir de WindowManager
    • Les nouvelles méthodes getSize() et getRectSize() permettent aux applications d'obtenir la taille brute de l'écran.
  • Nouveaux styles publics "holographiques"
    • La plate-forme expose désormais une variété de styles "holographiques" publics pour le texte, les widgets de barre d'action et les onglets, entre autres. Consultez R.style pour obtenir la liste complète.
  • LocalActivityManager, ActivityGroup et LocalActivityManager sont désormais obsolètes
    • Les nouvelles applications doivent utiliser des fragments plutôt que ces classes. Pour continuer à exécuter votre application sur les anciennes versions de la plate-forme, vous pouvez utiliser la bibliothèque Support v4 (bibliothèque de compatibilité), disponible dans le SDK Android. La bibliothèque Support v4 fournit une version de l'API Fragment compatible avec Android 1.6 (niveau d'API 4).
    • Pour les applications développées pour Android 3.0 (niveau d'API 11) ou version ultérieure, les onglets sont généralement présentés dans l'UI à l'aide du nouveau ActionBar.newTab() et des API associées pour les placer dans leur zone de barre d'action.

Framework multimédia

  • Les applications qui utilisent le fournisseur multimédia de la plate-forme (MediaStore) peuvent désormais lire les données multimédias directement à partir de la carte SD amovible, si l'appareil le permet. Les applications peuvent également interagir directement avec les fichiers de carte SD, à l'aide de l'API MTP.

Graphiques

Framework IME

  • Nouvelle méthode getModifiers() pour récupérer l'état actuel des touches de modification.

Framework USB

  • Nouvelle méthode getRawDescriptors() permettant de récupérer les descripteurs USB bruts de l'appareil. Vous pouvez utiliser cette méthode pour accéder aux descripteurs non compatibles directement via les API de niveau supérieur.

Réseau

Téléphonie

Utilitaires principaux

  • Utilitaires parcellables
  • Binder et IBinder
    • La nouvelle méthode dumpAsync() dans Binder et IBinder permet aux applications de vider les données dans un fichier spécifié, en veillant à ce que la cible s'exécute de manière asynchrone.
    • Le nouveau code de transaction de protocole IBinder TWEET_TRANSACTION permet aux applications d'envoyer un tweet à l'objet cible.

Nouvelles constantes de fonctionnalités

La plate-forme ajoute de nouvelles constantes de fonctionnalités matérielles que vous pouvez déclarer dans leurs fichiers manifestes d'application pour informer les entités externes telles que Google Play des fonctionnalités matérielles et logicielles requises. Vous déclarez ces constantes et d'autres constantes de fonctionnalité dans les éléments de fichier manifeste <uses-feature>.

Google Play filtre les applications en fonction de leurs attributs <uses-feature> pour s'assurer qu'elles ne sont disponibles que sur les appareils sur lesquels leurs exigences sont satisfaites.

  • Constantes de fonctionnalité pour les exigences en mode Paysage ou Portrait

    Android 3.2 introduit de nouvelles constantes de fonctionnalités qui permettent aux applications de spécifier si elles nécessitent un affichage en mode paysage, en mode portrait ou les deux. Déclarer ces constantes indique que l'application ne doit pas être installée sur un appareil qui n'offre pas l'orientation associée. À l'inverse, si l'une des constantes ou les deux ne sont pas déclarées, cela signifie que l'application n'a pas de préférence pour les orientations non déclarées et peut être installée sur un appareil qui ne les offre pas.

    Une application standard qui fonctionne correctement en mode paysage et portrait n'a normalement pas besoin de déclarer d'exigence d'orientation. À la place, une application conçue principalement pour une orientation, telle qu'une application conçue pour un téléviseur, peut déclarer l'une des constantes pour s'assurer qu'elle n'est pas disponible pour les appareils qui ne proposent pas cette orientation.

    Si l'une des activités déclarées dans le fichier manifeste demande à s'exécuter dans une orientation spécifique à l'aide de l'attribut android:screenOrientation, cela déclare également que l'application nécessite cette orientation.

  • Autres constantes de fonctionnalité

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 3.2 (niveau d'API 13), consultez le rapport de différences des API.

Niveau d'API

La plate-forme Android 3.2 fournit une version mise à jour de l'API du framework. L'API Android 3.2 est associée à un identifiant entier (13) 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.2 dans votre application, vous devez compiler l'application avec la bibliothèque Android fournie dans la plate-forme du SDK Android 3.2. Selon vos besoins, vous devrez peut-être également ajouter un attribut android:minSdkVersion="13" à 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 ?