API Android 3.2

Niveau d'API : 13

Android 3.2 (HONEYCOMB_MR2) est une version incrémentielle de la plate-forme qui ajoute pour les utilisateurs et les développeurs. Les sections ci-dessous offrent un aperçu des nouvelles fonctionnalités et des 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 votre application sur 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 un plus grand nombre 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 les applications de taille fixe sur des appareils plus grands. Le nouveau mode offre une à l'échelle du pixel à l'étirement standard de l'interface utilisateur pour les applications qui ne sont pas conçus pour fonctionner sur des écrans plus grands, comme les tablettes. Le nouveau mode est accessible aux utilisateurs depuis une icône de menu dans la barre système, pour les applications qui ont besoin de la prise en charge de la 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 directement des fichiers multimédias de la carte SD aux applications qui les utilisent. Une installation système rend les fichiers accessible aux applications 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 pour l'API Screen Support de la plate-forme afin de offrent aux développeurs des moyens supplémentaires de gérer l'interface utilisateur des applications sur l'ensemble 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 à taille fixe et les applications avec des la prise en charge de différentes tailles d'écran, la plate-forme propose également un nouveau mode de compatibilité qui affiche l'interface utilisateur sur une zone d'écran plus petite, puis la met à l'échelle pour remplir l'espace disponible sur 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 compter sur la plate-forme pour fournissent une abstraction de densité, ce qui signifie que les applications n'ont pas besoin compenser les différences de densité de pixels réelle entre les appareils. Toi peuvent concevoir l'interface utilisateur de l'application en fonction de la quantité l'espace disponible. La plate-forme exprime l'espace disponible à l'aide de trois nouvelles les 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"). Il s'agit de la hauteur ou de la largeur de l'écran, la plus petite des deux. Pour un écran en mode portrait, smallestWidth est généralement basée sur sa largeur, tandis qu'en mode paysage, elle est basée en fonction de sa hauteur. Dans tous les cas, la valeur de smallestWidth est dérivée d'une caractéristique fixe du à l'écran et sa 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'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 espace horizontal ou vertical actuel disponible pour la mise en page de l'application, mesuré dans "dp" unités, à 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 de l'orientation paysage à l'orientation portrait.

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. Vous pouvez également gérer UI en fonction de la largeur ou de la hauteur actuelles, selon les besoins C'est pourquoi l'API fournit ces outils:

  • Nouveaux qualificatifs de ressources pour cibler des mises en page et d'autres ressources avec une largeur, une hauteur ou une largeur minimale, et
  • Nouveaux attributs de fichier manifeste, pour spécifier la taille maximale plage de compatibilité des écrans

De plus, les applications peuvent toujours interroger le système et gérer l'UI et le chargement 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 plus directement les écrans via smallestWidth, la largeur et la hauteur, il est utile de comprendre les caractéristiques des différents types d'écrans. Le tableau ci-dessous fournit quelques exemples, mesurés en dp unités de mesure.

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 480 x 800 480
Tablette 7 pouces mdpi 600x1024 600
Tablette 10 pouces mdpi 800 x 1 280 800

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

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

Les nouveaux qualificateurs de ressources d'Android 3.2 vous permettent de mieux cibler vos mises en page pour des plages de tailles d'écran. Les qualificatifs permettent de créer des ressources des configurations conçues pour une largeur minimale spécifique (smallestWidth), une largeur actuelle ou la 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 de smallestWidth de l'écran est constante, quelle que soit l'orientation. Exemples: sw320dp, sw720dp et sw720dp.
  • wNNNdp et hNNNdp : spécifient la valeur minimale largeur ou hauteur selon laquelle la ressource doit être utilisée, mesurée en "dp" unités de mesure. Comme indiqué ci-dessus, la largeur et la hauteur d'un écran sont relatives à son orientation et changent chaque fois que l'orientation change. Exemples: w320dp, w720dp et h1024dp.

Si nécessaire, vous pouvez également créer plusieurs configurations de ressources qui se chevauchent. Par exemple, vous pouvez ajouter des tags à certaines ressources pour les utiliser sur n'importe quel écran de plus de 480 pixels. 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 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 qualificatifs ou existants.

Voici quelques exemples basés sur les dimensions typiques listées précédemment. vous pouvez utiliser les 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 ignorent 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. Ici, 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 Utiliser les 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çu pour fonctionner, ainsi que sur le plus grand écran sur lequel il est conçu. sans avoir besoin du nouvel écran du système. mode de compatibilité. À l'instar des qualificatifs de ressources décrits ci-dessus, le nouveau Les attributs du fichier manifeste spécifient la plage d'écrans compatibles avec l'application, comme spécifié par smallestWidth.

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

  • android:compatibleWidthLimitDp="numDp" : ceci permet de spécifier la largeur maximale de smallestWidth sur laquelle l'application peut s'exécuter sans avoir besoin d'un 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" : ceci permet de spécifier la largeur maximale de smallestWidth sur laquelle l'application est conçu pour fonctionner. Si l'écran actuel est plus grand que la valeur spécifiée, le système force l'application en mode de compatibilité de l'écran pour assurer le meilleur affichage 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 l'écran actuel est plus petit que la valeur spécifiée, le système considère l'application comme incompatible avec l'appareil, mais ne l'empêche pas d'être installée et exécutée.

Remarque:Pour le moment, Google Play ne filtre pas applications en fonction de l'un des attributs ci-dessus. La prise en charge du filtrage sera ajoutée dans une version ultérieure de la plate-forme. Les applications qui nécessitent le filtrage basé sur la taille de l'écran peut utiliser le <supports-screens> existant .

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

Mode de compatibilité de l'écran

Android 3.2 propose un nouveau mode de compatibilité d'écran pour les applications déclarant explicitement qu'ils ne prennent pas en charge les écrans aussi grands que celui qu'ils 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 comme option utilisateur, pour les applications qui en ont besoin. Les utilisateurs peuvent activer et désactiver le mode zoom à l'aide d'une des commandes disponibles dans la barre système.

Comme le nouveau mode de compatibilité de l'écran ne convient peut-être pas à tous applications, la plate-forme permet à l'application de la désactiver à l'aide d'un fichier manifeste . Lorsque l'application est désactivée par l'application, le système ne propose pas de "zoom" compatibilité pour les utilisateurs lorsque l'application est en cours d'exécution.

Remarque:Pour obtenir des informations importantes sur la façon dont pour contrôler le mode de compatibilité de vos applications, consultez l'article Nouveau mode pour les applications sur les grands écrans sur le site Blog des développeurs.

Nouvelle densité d'écran pour les téléviseurs 720p et d'autres 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 résolution d'environ 213 PPP. Les applications peuvent interroger la nouvelle densité dans densityDpi et peut utiliser Le nouveau qualificatif tvdpi permet d'ajouter des tags aux ressources pour les téléviseurs et appareils similaires. Exemple :

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

En général, les applications n'ont pas besoin de fonctionner avec cette densité. Pour les situations Lorsque la 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 l'état des informations extraites d'une instance de fragment saveFragmentInstanceState()
    • Nouvelle méthode saveFragmentInstanceState() enregistre l'état actuel de l'instance pour le 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 détaché 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 une animation spécifique ressources à exécuter pour les opérations d'entrée et de sortie, et en particulier lorsque en faisant apparaître la pile "Retour". L'implémentation existante ne tient pas compte pour connaître 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 pour obtenir la taille d'affichage à partir de WindowManager <ph type="x-smartling-placeholder">
      </ph>
    • 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. Pour obtenir la liste complète, consultez R.style.
  • LocalActivityManager, ActivityGroup et LocalActivityManager est désormais obsolète
    • 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. Version d'assistance v4 La bibliothèque fournit une version de l'API Fragment compatible jusqu'au 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 de la nouvelle ActionBar.newTab() et les API associées pour placer des onglets dans la zone de la barre d'action.

Cadre pour les médias

  • 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 la 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() pour récupérer les descripteurs USB bruts de l'appareil. Vous pouvez utiliser permettant d'accéder aux descripteurs qui ne sont pas directement pris en charge via la au niveau des API.

Réseau

Téléphonie

Utilitaires principaux

  • Utilitaires Parcelable <ph type="x-smartling-placeholder">
  • Liant et IBinder <ph type="x-smartling-placeholder">
      </ph>
    • La nouvelle méthode dumpAsync() dans Binder et IBinder permet aux applications de vider un fichier spécifié, ce qui garantit 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, afin d'informer les entités externes telles que Google Jeu des capacités matérielles et logicielles requises. Vous déclarez ces éléments et d'autres constantes de fonctionnalités 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 sur lesquels les conditions requises sont remplies.

  • 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 qu'elle peut être installée sur un appareil qui ne les offre pas.

    Une application type qui fonctionne correctement en mode paysage et portrait n'a normalement pas besoin de déclarer une 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 signifie également que l'application nécessite cette orientation.

  • Autres constantes de caractéristiques <ph type="x-smartling-placeholder">

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.2 (API Niveau 13), consultez la page API rapport sur les différences.

Niveau d'API

La plate-forme Android 3.2 propose 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 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 ?