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 de développement.

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 sous Android 3.2, utilisez Android SDK Manager afin de 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 du système pour garantir une expérience utilisateur de qualité 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 un nouveau moyen d'afficher les applications à taille fixe sur les appareils plus grands. Le nouveau mode offre une alternative au pixel près à l'étirement de l'interface utilisateur standard pour les applications qui ne sont pas conçues pour s'exécuter sur des écrans plus grands, comme les tablettes. Le nouveau mode est accessible aux utilisateurs à partir d'une icône de menu dans la barre système, pour les applications nécessitant une compatibilité.

  • 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 dans les applications qui les utilisent. Une installation système rend les fichiers accessibles aux applications à partir du Media Store système.

Nouvelles fonctionnalités pour les développeurs

  • API étendue pour la gestion des écrans

    Android 3.2 introduit des extensions dans l'API Screen Support de la plate-forme afin d'offrir aux développeurs d'autres moyens de gérer l'interface utilisateur des applications sur la gamme d'appareils Android. L'API inclut de nouveaux qualificateurs de ressources et de nouveaux attributs de fichier manifeste qui vous permettent de contrôler plus précisément l'affichage de vos applications selon les différentes tailles, plutôt que de vous appuyer sur des catégories de tailles généralisées.

    Pour garantir le meilleur affichage possible pour les applications et applications de taille fixe, 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 Screen Support et les commandes qu'elle fournit, consultez les sections ci-dessous.

Présentation de l'API

API Screens Support

Android 3.2 introduit de nouveaux écrans compatibles avec des API qui vous permettent de mieux contrôler l'affichage de leurs applications sur différentes tailles d'écran. L'API s'appuie sur l'API existante compatible avec les écrans, y compris le modèle de densité d'écran généralisée de la plate-forme, mais l'étend en 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é (telles que 600 dp ou 720 dp), plutôt que par leur taille d'écran généralisée (grande ou très grande).

Lors de la conception de l'interface utilisateur d'une application, vous pouvez toujours compter 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é réelle de pixels entre les appareils. Vous pouvez concevoir l'interface utilisateur de l'application en fonction de la quantité d'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 valeur 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, il s'agit de la plus courte des deux. Pour un écran en mode portrait, la valeur smallestWidth se base normalement 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 la valeur 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'interface utilisateur de l'application doit être dessinée, sans inclure les zones d'écran réservées par le système.
  • En revanche, les valeurs width et height d'un écran représentent l'espace horizontal ou vertical actuel disponible pour la mise en page de l'application, mesuré en unités "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 change d'orientation entre les modes paysage et portrait.

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

  • Nouveaux qualificatifs de ressource pour cibler les mises en page et d'autres ressources avec une valeur minimale de smallestWidth, width ou height, et
  • 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'interface utilisateur 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 les valeurs smallestWidth, la largeur et la hauteur, il est utile de comprendre les caractéristiques typiques 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 320x480 320
Petite tablette/Grand téléphone mdpi 480x800 480
Tablette 7 pouces mdpi 600x1024 600
Tablette 10 pouces mdpi 800x1280 800

Les sections ci-dessous fournissent plus d'informations sur les nouveaux qualificatifs d'écran et attributs de fichier manifeste. Pour en savoir plus sur l'utilisation de l'API de compatibilité des écrans, consultez la page Compatibilité avec plusieurs écrans.

Nouveaux qualificateurs de ressources pour la prise en charge des écrans

Les nouveaux qualificatifs de ressource 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 valeur minimale spécifique (smallestWidth, largeur actuelle ou hauteur actuelle) mesurée 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 minimales d'utilisation de la ressource, mesurée en unités "dp". Comme mentionné ci-dessus, la largeur et la hauteur d'un écran dépendent de son orientation 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 une utilisation sur un écran de plus de 480 dp, d'autres pour une largeur supérieure à 600 dp et d'autres pour une largeur supérieure à 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 un contrôle précis des ressources chargées sur un écran donné, vous pouvez taguer les ressources avec un seul qualificatif, ou combiner plusieurs qualificatifs nouveaux ou existants.

Sur la base des dimensions classiques listées précédemment, voici quelques exemples d'utilisation des nouveaux qualificatifs:

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 les tailles d'écran

Le framework propose un nouvel ensemble d'attributs manifestes <supports-screens> qui vous permettent de gérer la compatibilité de votre application avec différentes tailles d'écran. Plus précisément, vous pouvez spécifier le plus grand et le plus petit écran sur lequel votre application est conçue pour s'exécuter, ainsi que le plus grand écran sur lequel elle est conçue, sans avoir besoin du nouveau mode de compatibilité d'é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 spécifié par la valeur "smallestWidth".

Les nouveaux attributs de fichier manifeste pour la compatibilité avec les écrans sont les suivants:

  • android:compatibleWidthLimitDp="numDp" : cet attribut vous permet de spécifier la valeur "smallestWidth" maximale sur laquelle l'application peut s'exécuter sans avoir besoin du mode de compatibilité. Si la taille de l'écran actuel dépasse la valeur spécifiée, le système affiche l'application en mode normal, mais permet à l'utilisateur de passer éventuellement en mode de compatibilité via un paramètre de la barre système.
  • android:largestWidthLimitDp="numDp" : cet attribut vous permet de spécifier la valeur la plus élevée (smallestWidth) sur laquelle l'application est conçue pour s'exécuter. Si la taille de l'écran actuel est supérieure à la valeur spécifiée, le système force l'application à passer en mode de compatibilité de l'écran afin de garantir un affichage optimal sur l'écran actuel.
  • android:requiresSmallestWidthDp="numDp" : cet attribut vous permet de spécifier la valeur minimale de smallestWidth sur laquelle l'application peut s'exécuter. Si l'écran actuel est inférieur à 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:Pour le moment, Google Play ne filtre pas les applications en fonction 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 en savoir plus sur l'utilisation des nouveaux attributs, consultez Déclarer une taille d'écran compatible.

Mode de compatibilité de l'écran

Android 3.2 fournit un nouveau mode de compatibilité d'écran pour les applications déclarant explicitement qu'elles ne prennent pas en charge les écrans aussi grands que celui sur lequel elles s'exécutent. Ce nouveau mode "zoom" est basé sur une mise à l'échelle en pixels : il affiche l'application dans une zone d'écran plus petite, puis adapte les pixels pour remplir l'écran actuel.

Par défaut, le système propose le mode de compatibilité de l'écran comme option utilisateur pour les applications qui le nécessitent. 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 peut ne pas être adapté à toutes les applications, la plate-forme autorise l'application à le désactiver à l'aide d'attributs de fichier manifeste. Lorsque l'application est désactivée par l'application, le système ne propose pas d'option de compatibilité "zoom" pour les utilisateurs lorsque l'application est en cours d'exécution.

Remarque:Pour obtenir des informations importantes sur le contrôle du mode de compatibilité dans vos applications, consultez l'article Nouveau mode pour les applications sur grand écran 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 des 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 une densité de pixels d'environ 213 ppp. Les applications peuvent interroger la nouvelle densité dans densityDpi et utiliser le nouveau qualificatif tvdpi pour taguer des ressources pour les téléviseurs et les appareils similaires. Par exemple :

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

En général, il n'est pas nécessaire que les applications fonctionnent avec cette densité. Dans les cas où une sortie est nécessaire pour un écran de 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 actuel de l'instance 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 création initiale.
    • La nouvelle méthode de rappel onViewCreated() informe le fragment que onCreateView() a été renvoyé, 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 d'associer ou de dissocier des fragments dans l'interface utilisateur.
    • 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 et de sortie, et plus particulièrement lors de l'affichage de la pile "Retour". L'implémentation existante ne prend pas en compte le comportement différent des fragments lors de l'affichage de la pile "Retour".
  • Informations sur la taille de l'écran dans ActivityInfo et ApplicationInfo.
  • Aides permettant d'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 "holographiques" publics
    • La plate-forme propose désormais divers styles "holographiques" publics pour le texte, les widgets et les onglets de barre d'action, et plus encore. Consultez R.style pour obtenir la liste complète.
  • Abandon de LocalActivityManager, ActivityGroup et LocalActivityManager.
    • Les nouvelles applications doivent utiliser des fragments au lieu de ces classes. Pour continuer à exécuter vos applications 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 sous Android 3.0 (niveau d'API 11) ou version ultérieure, les onglets sont généralement présentés dans l'interface utilisateur à l'aide du nouveau ActionBar.newTab() et des API associées permettant de placer des onglets dans la zone de leur barre d'action.

Framework pour les médias

  • Les applications qui utilisent le fournisseur de contenus multimédias 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 la carte SD, à l'aide de l'API MTP.

Graphismes

Framework IME

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

Framework USB

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

Réseau

Téléphonie

Principaux utilitaires

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

Nouvelles constantes de caractéristiques

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

Google Play filtre les applications en fonction de leurs attributs <uses-feature>, afin de s'assurer qu'elles ne sont disponibles que sur les appareils qui répondent à leurs critères.

  • Constantes de fonctionnalités 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. La déclaration de ces constantes indique que l'application ne doit pas être installée sur un appareil qui ne propose 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 qu'elle peut être installée sur un appareil qui ne les propose pas.

    Une application type qui fonctionne correctement en mode paysage et en mode portrait n'aurait normalement pas besoin de déclarer une exigence d'orientation. Au contraire, une application conçue principalement pour une orientation, par exemple 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 fournissent pas cette orientation.

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

  • Autres constantes de caractéristiques

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.2 (niveau d'API 13), consultez le rapport sur les différences d'API.

Niveau d'API

La plate-forme Android 3.2 fournit une version mise à jour de l'API du framework. Un identifiant entier (13) est attribué à l'API Android 3.2, 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.2 dans votre application, vous devez compiler l'application avec la bibliothèque Android fournie dans la plate-forme SDK Android 3.2. En fonction de 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 ?