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 une vue d'ensemble des nouvelles fonctionnalités et des API de développement.

Pour les développeurs, la plate-forme Android 3.2 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 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 une gamme plus large de tablettes

    Android 3.2 inclut diverses optimisations sur l'ensemble du 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 multimédia à 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 de prise en charge de l'écran de la plate-forme pour 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 attributs de fichier manifeste, qui vous permettent de contrôler plus précisément les applications s'affichent dans différentes tailles, plutôt que de s'appuyer catégories de taille.

    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 la 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 offrent plus de contrôler l'affichage de leurs applications sur différentes tailles d'écran. L'API s'appuie sur l'API Screens-Support existante, y compris modèle généralisé de densité d'écran, mais l'étend avec la possibilité de cibler des plages d'écrans 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), au lieu par leur taille d'écran généralisée (par exemple grande ou XL)

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"). De la hauteur de l'écran ou est la plus courte 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 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 la pluspetiteLargeur est importante pour les applications, car elle représente la largeur la plus courte possible dans lequel l'interface utilisateur de l'application doit être dessinée, à l'exclusion des zones de l'é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 change lorsque l'utilisateur passe du mode paysage au mode paysage. et en mode portrait.

La nouvelle API Screens Supports est conçue pour vous permettre de gérer l'UI de l'application en fonction de la 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:

  • De nouveaux qualificateurs de ressources pour le ciblage des mises en page et d'autres ressources dans une la valeur minimale (smallestWidth, width ou height) 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 la densité et la taille en dp.

Type Densité (généralisée) Dimensions (dp) smallestWidth (dp)
Numéro de 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 les attributs du fichier manifeste. Pour obtenir des informations complètes sur l'utilisation de l'écran API d'assistance, consultez la section Prise en charge de Écrans :

Nouveaux qualificateurs de ressources pour la compatibilité des é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 La ressource doit être utilisée, mesurée en "dp" unités de mesure. 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. En tant que mentionnées ci-dessus, la largeur et la hauteur d'un écran dépendent de l'orientation l'écran et l'adaptera à chaque changement d'orientation. 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. Quand ? 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 de les ressources chargées sur un écran donné, vous pouvez leur ajouter des tags ou combiner plusieurs qualificatifs nouveaux 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 ignoreront les nouveaux qualificatifs. Vous pourrez donc mélangez-les 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 obtenir des informations complètes sur l'utilisation des nouveaux qualificatifs, consultez la section Utiliser de nouvelles des qualificatifs de taille.

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

Le framework propose un nouvel ensemble d'attributs de fichier manifeste <supports-screens> qui permettent la prise en charge de votre application pour 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 du 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 la taille de l'écran actuel est supérieure à la valeur spécifiée, le système affiche l'application en mode normal, mais permet à l'utilisateur de passer de manière facultative 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 supérieur à la valeur spécifiée, le système force l'application à passer en mode de compatibilité de l'écran, pour garantir sur l'écran actuel.
  • android:requiresSmallestWidthDp="numDp" : ceci permet de spécifier la largeur minimale (smallestWidth) 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 que l'application est incompatible avec l'appareil, mais ne l'empêche pas d’être installé et exécuté.

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 "zoom" est à l'échelle du pixel : il affiche l'application dans une zone d'écran plus petite, puis redimensionne les pixels pour 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é dans 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 fonctionnant sur les téléviseurs 720p ou autres avec é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 de l'interface utilisateur peuvent être mis à l'échelle automatiquement par la plate-forme.

Framework d'UI

  • Fragments <ph type="x-smartling-placeholder">
      </ph>
    • La nouvelle classe Fragment.SavedState contient l'état des informations récupérées depuis une instance de fragment via 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.
    • Nouvelle méthode setInitialSavedState() définit l'état enregistré initial d'un fragment lors de sa construction initiale.
    • La nouvelle méthode de rappel onViewCreated() informe le fragment que onCreateView() est 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 détaché de l'UI.
    • Nouveau 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 <ph type="x-smartling-placeholder">
  • 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.
  • Nouvelle version "holographique" publique styles <ph type="x-smartling-placeholder">
      </ph>
    • La plate-forme propose désormais une variété d'images holographiques publiques styles pour afficher du texte, des widgets et des onglets de la barre d'action, et bien plus encore. Voir R.style pour obtenir la liste complète.
  • LocalActivityManager, ActivityGroup et LocalActivityManager est désormais obsolète <ph type="x-smartling-placeholder">
      </ph>
    • Les nouvelles applications doivent utiliser des fragments au lieu de ces classes. À continuent de fonctionner sur d'anciennes versions de la plate-forme, vous pouvez utiliser la version 4 Bibliothèque (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 compatible avec l'appareil. 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 du périphérique. 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 de base

  • Utilitaires Parcelable <ph type="x-smartling-placeholder">
  • Liant et IBinder <ph type="x-smartling-placeholder">
      </ph>
    • Nouvelle méthode dumpAsync() dans Binder et IBinder permettent aux applications vide dans un fichier spécifié, ce qui garantit 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 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 des 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 un affichage est requis en mode paysage ou portrait, ou les deux. La déclaration de 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 qu'elle s'exécute dans une orientation spécifique, à l'aide de l'attribut android:screenOrientation, cela indique é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 se voit attribuer un identifiant sous forme de nombre entier, 13, 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.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 pourrait devez également ajouter un android:minSdkVersion="13" à l'élément <uses-sdk> dans le fichier fichier manifeste.

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