Cette page a été traduite par l'API Cloud Translation.

Changements de comportement sous Android 5.0

Niveau d'API: 21

En plus de nouvelles fonctionnalités, Android 5.0 apporte diverses modifications au système et au comportement de l'API. Ce document met en évidence certains des principaux changements que vous devez comprendre et prendre en compte dans vos applications.

Si vous avez déjà publié une application pour Android, sachez qu'elle peut être affectée par ces modifications dans Android 5.0.

Pour une présentation générale des nouvelles fonctionnalités de la plate-forme, consultez les points forts d'Android Lollipop.

Vidéos

Dev Byte : What's New in Android 5.0 (Octet du développeur : Nouveautés d'Android 5.0)

Dev Byte: Notifications

Environnement d'exécution Android Runtime ("ART")

Sous Android 5.0, l'environnement d'exécution ART remplace Dalvik comme valeur par défaut de la plate-forme. L'environnement d'exécution ART a été introduit dans Android 4.4 à titre expérimental.

Pour une présentation des nouvelles fonctionnalités d'ART, consultez la section Présentation d'ART. Voici quelques-unes des nouvelles fonctionnalités principales:

Compilation anticipée (AOT)
Amélioration de la récupération de mémoire
Amélioration de l'assistance au débogage

La plupart des applications Android devraient fonctionner sans aucune modification sous ART. Cependant, certaines techniques qui fonctionnent sur Dalvik ne fonctionnent pas sur ART. Pour en savoir plus sur les problèmes les plus importants, consultez Vérifier le comportement des applications sur l'environnement d'exécution Android Runtime (ART). Soyez particulièrement attentif dans les cas suivants:

Votre application utilise JNI (Java Native Interface) pour exécuter du code C/C++.
Vous utilisez des outils de développement qui génèrent du code non standard (certains obscurcisseurs, par exemple).
Vous utilisez des techniques incompatibles avec la récupération de mémoire pour le compactage.

Notifications

Assurez-vous que vos notifications tiennent compte de ces modifications apportées à Android 5.0. Pour en savoir plus sur la conception de notifications pour Android 5.0 ou version ultérieure, consultez le guide de conception de notifications.

Style Material Design

Les notifications sont affichées avec un texte sombre sur les arrière-plans blancs (ou très clairs) pour correspondre aux nouveaux widgets Material Design. Assurez-vous que toutes vos notifications s'affichent correctement avec le nouveau jeu de couleurs. Si vos notifications semblent incorrectes, corrigez-les:

Utilisez setColor() pour définir une couleur d'accentuation dans un cercle derrière votre icône.
Modifiez ou supprimez les composants qui comportent des couleurs. Le système ignore tous les canaux non alpha dans les icônes d'action et dans l'icône de notification principale. Vous devez supposer que ces icônes sont en version alpha uniquement. Le système affiche les icônes de notification en blanc et les icônes d'action en gris foncé.

Son et vibreur

Si vous ajoutez actuellement des sons et des vibrations à vos notifications à l'aide des classes Ringtone, MediaPlayer ou Vibrator, supprimez ce code afin que le système puisse présenter correctement les notifications en mode priorité. Utilisez plutôt les méthodes Notification.Builder pour ajouter des sons et des vibrations.

Si l'appareil est défini sur RINGER_MODE_SILENT, il passe dans le nouveau mode de priorité. L'appareil quitte le mode Priorité si vous le définissez sur RINGER_MODE_NORMAL ou RINGER_MODE_VIBRATE.

Auparavant, Android utilisait STREAM_MUSIC comme flux principal pour contrôler le volume sur les tablettes. Sous Android 5.0, le flux de volume principal pour les téléphones et les tablettes est désormais unifié et contrôlé par STREAM_RING ou STREAM_NOTIFICATION.

Visibilité sur l'écran de verrouillage

Par défaut, les notifications s'affichent désormais sur l'écran de verrouillage de l'appareil Android 5.0. Les utilisateurs peuvent choisir de protéger les informations sensibles contre toute exposition. Dans ce cas, le système masque automatiquement le texte affiché par la notification. Pour personnaliser cette notification masquée, utilisez setPublicVersion().

Si la notification ne contient pas d'informations personnelles ou si vous souhaitez autoriser la commande de lecture multimédia sur la notification, appelez la méthode setVisibility() et définissez le niveau de visibilité de la notification sur VISIBILITY_PUBLIC.

Lecture de contenus multimédias

Si vous implémentez des notifications qui présentent un état de lecture multimédia ou des commandes de transport, envisagez d'utiliser le nouveau modèle Notification.MediaStyle au lieu d'un objet RemoteViews.RemoteView personnalisé. Quelle que soit l'approche que vous choisissez, veillez à définir la visibilité de la notification sur VISIBILITY_PUBLIC afin que vos commandes soient accessibles depuis l'écran de verrouillage. Notez qu'à partir d'Android 5.0, le système n'affiche plus les objets RemoteControlClient sur l'écran de verrouillage. Pour en savoir plus, consultez la section Si votre application utilise RemoteControlClient.

Notification prioritaire

Les notifications peuvent désormais s'afficher dans une petite fenêtre flottante (également appelée notification prioritaire) lorsque l'appareil est actif (c'est-à-dire que l'appareil est déverrouillé et que son écran est allumé). Ces notifications ressemblent à la forme compacte de votre notification, si ce n'est que la notification prioritaire affiche également des boutons d'action. Les utilisateurs peuvent interagir avec une notification prioritaire ou l'ignorer sans quitter l'application actuelle.

Voici quelques exemples de conditions pouvant déclencher des notifications prioritaires:

L'activité de l'utilisateur est en mode plein écran (l'application utilise fullScreenIntent).
La notification a un niveau de priorité élevé et utilise des sonneries ou des vibrations

Si votre application implémente des notifications dans l'un de ces scénarios, assurez-vous que les notifications prioritaires sont correctement présentées.

Commandes multimédias et RemoteControlClient

La classe RemoteControlClient est désormais obsolète. Passez à la nouvelle API MediaSession dès que possible.

Les écrans de verrouillage sous Android 5.0 n'affichent pas les commandes de transport pour votre MediaSession ou RemoteControlClient. Au lieu de cela, votre application peut fournir des commandes de lecture multimédia à partir de l'écran de verrouillage via une notification. Cela donne à votre application plus de contrôle sur la présentation des boutons multimédias, tout en offrant une expérience cohérente aux utilisateurs sur les appareils verrouillés et non verrouillés.

Android 5.0 introduit un nouveau modèle Notification.MediaStyle à cet effet. Notification.MediaStyle convertit les actions de notification que vous avez ajoutées avec Notification.Builder.addAction() en boutons compacts intégrés aux notifications de lecture de contenus multimédias de votre application. Transmettez votre jeton de session à la méthode setSession() pour informer le système que cette notification contrôle une session multimédia en cours.

Veillez à définir la visibilité de la notification sur VISIBILITY_PUBLIC pour qu'elle puisse s'afficher sans danger sur n'importe quel écran de verrouillage (sécurisée ou autre). Pour en savoir plus, consultez la section Notifications sur l'écran de verrouillage.

Pour afficher les commandes de lecture multimédia si votre application s'exécute sur la plate-forme Android TV ou Wear, implémentez la classe MediaSession. Vous devez également implémenter MediaSession si votre application doit recevoir des événements de bouton multimédia sur les appareils Android.

getRecentTasks()

Avec le lancement de la nouvelle fonctionnalité de tâches simultanées de documents et d'activités dans Android 5.0 (voir Documents et activités simultanés dans l'écran récent ci-dessous), la méthode ActivityManager.getRecentTasks() est désormais obsolète pour améliorer la confidentialité des utilisateurs. Pour assurer la rétrocompatibilité, cette méthode renvoie toujours un petit sous-ensemble de ses données, y compris les propres tâches de l'application appelante et éventuellement d'autres tâches non sensibles (telles que Home). Si votre application récupère ses propres tâches à l'aide de cette méthode, utilisez plutôt getAppTasks() pour récupérer ces informations.

Compatibilité 64 bits dans le NDK Android

Android 5.0 est compatible avec les systèmes 64 bits. L'amélioration 64 bits augmente l'espace d'adressage et améliore les performances, tout en continuant à assurer la compatibilité totale des applications 32 bits existantes. La compatibilité 64 bits améliore également les performances d'OpenSSL pour la cryptographie. En outre, cette version introduit de nouvelles API natives du NDK multimédia, ainsi qu'une compatibilité native avec OpenGL ES (GLES) 3.1.

Pour utiliser la compatibilité 64 bits fournie dans Android 5.0, téléchargez et installez la révision 10c du NDK à partir de la page du NDK Android. Consultez les notes de version de la révision 10c pour en savoir plus sur les modifications importantes et les corrections de bugs apportées au NDK.

Lier à un service

La méthode Context.bindService() nécessite désormais un Intent explicite et génère une exception si elle est associée à un intent implicite. Pour vous assurer que votre application est sécurisée, utilisez un intent explicite lors du démarrage ou de la liaison de votre Service, et ne déclarez pas de filtres d'intent pour le service.

WebView

Android 5.0 modifie le comportement par défaut de votre application.

Si votre application cible le niveau d'API 21 ou supérieur:
- Le système bloque par défaut le contenu mixte et les cookies tiers. Pour autoriser le contenu mixte et les cookies tiers, utilisez respectivement les méthodes setMixedContentMode() et setAcceptThirdPartyCookies().
- Le système choisit désormais intelligemment les parties du document HTML à dessiner. Ce nouveau comportement par défaut permet de réduire l'espace mémoire utilisé et d'améliorer les performances. Si vous souhaitez afficher l'ensemble du document en une seule fois, désactivez cette optimisation en appelant enableSlowWholeDocumentDraw().
Si votre application cible des niveaux d'API inférieurs à 21:le système autorise le contenu mixte et les cookies tiers, et affiche toujours l'intégralité du document en une seule fois.

Exigence d'unicité pour les autorisations personnalisées

Comme indiqué dans la présentation des autorisations, les applications Android peuvent définir des autorisations personnalisées afin de gérer l'accès aux composants de manière propriétaire, sans utiliser les autorisations système prédéfinies de la plate-forme. Les applications définissent des autorisations personnalisées dans les éléments <permission> déclarés dans leurs fichiers manifestes.

Dans de rares cas, la définition d'autorisations personnalisées constitue une approche légitime et sécurisée. Cependant, la création d'autorisations personnalisées est parfois inutile et peut même présenter un risque pour une application, en fonction du niveau de protection attribué aux autorisations.

Android 5.0 inclut un changement de comportement pour garantir qu'une seule application peut définir une autorisation personnalisée donnée, sauf si elle est signée avec la même clé que les autres applications qui définissent l'autorisation.

Applications utilisant des autorisations personnalisées en double

Toute application peut définir n'importe quelle autorisation personnalisée. Il peut donc arriver que plusieurs applications définissent la même autorisation personnalisée. Par exemple, si deux applications offrent une fonctionnalité similaire, elles peuvent obtenir le même nom logique pour leurs autorisations personnalisées. Les applications peuvent également intégrer des bibliothèques publiques courantes ou des exemples de code qui incluent eux-mêmes les mêmes définitions d'autorisations personnalisées.

Sous Android 4.4 et versions antérieures, les utilisateurs pouvaient installer plusieurs applications de ce type sur un appareil donné, bien que le système ait attribué le niveau de protection spécifié par la première application installée.

À partir d'Android 5.0, le système applique une nouvelle restriction d'unicité sur les autorisations personnalisées pour les applications signées avec des clés différentes. Désormais, une seule application sur un appareil peut définir une autorisation personnalisée donnée (déterminée par son nom), sauf si l'autre application définissant l'autorisation est signée avec la même clé. Si l'utilisateur tente d'installer une application avec une autorisation personnalisée en double et qu'il n'est pas signé avec la même clé que l'application résidente qui définit l'autorisation, le système bloque l'installation.

Points à prendre en compte pour votre application

À partir de la version 5.0 d'Android, les applications peuvent continuer à définir leurs propres autorisations personnalisées comme auparavant et demander des autorisations personnalisées à d'autres applications via le mécanisme <uses-permission>. Cependant, avec la nouvelle exigence introduite dans Android 5.0, vous devez évaluer soigneusement les impacts potentiels sur votre application.

Voici quelques points à prendre en compte:

Votre application déclare-t-elle des éléments <permission> dans son fichier manifeste ? Si oui, sont-elles réellement nécessaires au bon fonctionnement de votre application ou de votre service ? Ou pouvez-vous utiliser une autorisation système par défaut à la place ?
Si vous avez des éléments <permission> dans votre application, savez-vous d'où ils viennent ?
Souhaitez-vous vraiment que d'autres applications demandent vos autorisations personnalisées via <uses-permission> ?
Utilisez-vous un code récurrent ou un exemple de code dans votre application qui inclut des éléments <permission> ? Ces autorisations sont-elles réellement nécessaires ?
Vos autorisations personnalisées utilisent-elles des noms simples ou basés sur des termes courants que d'autres applications peuvent partager ?

Nouvelles installations et mises à jour

Comme indiqué ci-dessus, les nouvelles installations et mises à jour de votre application sur les appareils équipés d'Android 4.4 ou version antérieure ne sont pas concernées, et aucun changement de comportement n'est constaté. Pour les nouvelles installations et mises à jour sur les appareils équipés d'Android 5.0 ou version ultérieure, le système empêche l'installation de votre application s'il définit une autorisation personnalisée déjà définie par une application résidente existante.

Installations existantes avec la mise à jour du système Android 5.0

Si votre application utilise des autorisations personnalisées, et qu'elle est distribuée et installée à grande échelle, elle risque d'être affectée lorsque les utilisateurs reçoivent la mise à jour vers Android 5.0. Une fois la mise à jour du système installée, le système revalide les applications installées, y compris en vérifiant leurs autorisations personnalisées. Si votre application définit une autorisation personnalisée déjà définie par une autre application qui a déjà été validée et que votre application n'est pas signée avec la même clé que l'autre application, le système ne réinstalle pas votre application.

Recommandations

Sur les appareils équipés d'Android 5.0 ou version ultérieure, nous vous recommandons d'examiner immédiatement votre application, d'effectuer les ajustements nécessaires et de publier la version mise à jour dès que possible.

Si vous utilisez des autorisations personnalisées dans votre application, déterminez leur origine et si vous en avez réellement besoin. Supprimez tous les éléments <permission> de votre application, sauf si vous êtes certain qu'ils sont nécessaires au bon fonctionnement de votre application.
Dans la mesure du possible, envisagez de remplacer vos autorisations personnalisées par les autorisations système par défaut.
Si votre application nécessite des autorisations personnalisées, renommez-les pour qu'elles soient uniques, par exemple en les ajoutant au nom de package complet de votre application.
Si vous disposez d'une suite d'applications signées avec des clés différentes et que les applications accèdent à un composant partagé à l'aide d'une autorisation personnalisée, assurez-vous que l'autorisation personnalisée n'est définie qu'une seule fois, dans le composant partagé. Les applications qui utilisent le composant partagé ne doivent pas définir l'autorisation personnalisée. Elles doivent plutôt demander l'accès via le mécanisme <uses-permission>.
Si vous disposez d'une suite d'applications signées avec la même clé, chaque application peut définir les mêmes autorisations personnalisées que nécessaire. Le système autorise l'installation des applications de la manière habituelle.

Modifications de la configuration TLS/SSL par défaut

Android 5.0 modifie la configuration TLS/SSL par défaut utilisée par les applications pour le trafic HTTPS et tout autre trafic TLS/SSL:

Les protocoles TLSv1.2 et TLSv1.1 sont maintenant activés,
Les suites de chiffrement AES-GCM (AEAD) sont désormais activées,
Les suites de chiffrement MD5, 3DES, d'exportation et à clé statique ECDH sont désormais désactivées.
Il est préférable d’utiliser des suites de chiffrement de sécurité persistant (ECDHE et DHE).

Ces modifications peuvent entraîner des dysfonctionnements dans la connectivité HTTPS ou TLS/SSL dans les quelques cas indiqués ci-dessous.

Notez que l'outil de sécurité ProviderInstaller des services Google Play propose déjà ces modifications sur les versions de la plate-forme Android à partir d'Android 2.3.

Le serveur n'est compatible avec aucune des suites de chiffrement activées

Par exemple, un serveur peut n'accepter que les suites de chiffrement 3DES ou MD5. La solution privilégiée consiste à améliorer la configuration du serveur afin d'utiliser des suites et des protocoles de chiffrement plus puissants et plus modernes. Dans l'idéal, TLS v1.2 et AES-GCM doivent être activés, et les suites de chiffrement de sécurité persistant (ECDHE, DHE) doivent être activées et privilégiées.

Une autre solution consiste à modifier l'application afin d'utiliser un SSLSocketFactory personnalisé pour communiquer avec le serveur. La fabrique doit être conçue pour créer des instances SSLSocket dont certaines des suites de chiffrement requises par le serveur sont activées en plus des suites de chiffrement par défaut.

L'application fait des suppositions erronées concernant les suites de chiffrement utilisées pour se connecter au serveur

Par exemple, certaines applications contiennent un gestionnaire X509TrustManager personnalisé qui ne fonctionne pas, car il s'attend à ce que le paramètre authType soit RSA, mais rencontre ECDHE_RSA ou DHE_RSA.

Le serveur n'est pas compatible avec TLS v1.1, TLS v1.2 ou les nouvelles extensions TLS.

Par exemple, le handshake TLS/SSL avec un serveur est refusé ou bloqué par erreur. La solution privilégiée consiste à mettre à niveau le serveur afin qu'il soit conforme au protocole TLS/SSL. Le serveur va alors négocier correctement ces protocoles plus récents, ou TLSv1 ou des protocoles plus anciens, et ignorera les extensions TLS qu'il ne comprend pas. Dans certains cas, la désactivation de TLS v1.1 et TLS v1.2 sur le serveur peut constituer une mesure de protection jusqu'à ce que le logiciel serveur soit mis à niveau.

Une autre solution consiste à modifier l'application afin d'utiliser un SSLSocketFactory personnalisé pour communiquer avec le serveur. La fabrique doit être conçue pour créer des instances SSLSocket uniquement avec les protocoles activés qui sont correctement compatibles avec le serveur.

Compatibilité avec les profils gérés

Les administrateurs de l'appareil peuvent ajouter un profil géré à un appareil. Ce profil appartient à l'administrateur, ce qui lui permet de contrôler le profil géré tout en laissant le profil personnel de l'utilisateur et son espace de stockage sous le contrôle de l'utilisateur. Cette modification peut affecter le comportement de votre application existante de différentes manières.

Gérer les intents

Les administrateurs d'appareil peuvent restreindre l'accès aux applications système à partir du profil géré. Dans ce cas, si une application déclenche un intent à partir du profil géré qui serait normalement géré par cette application et qu'il n'existe pas de gestionnaire approprié pour l'intent sur le profil géré, l'intent génère une exception. Par exemple, l'administrateur de l'appareil peut empêcher les applications du profil géré d'accéder à l'application Appareil photo du système. Si votre application s'exécute sur le profil géré et appelle startActivityForResult() pour MediaStore.ACTION_IMAGE_CAPTURE, et qu'aucune application du profil géré ne peut gérer l'intent, cela génère une ActivityNotFoundException.

Pour éviter cela, vérifiez qu'il existe au moins un gestionnaire pour chaque intent avant de le déclencher. Pour rechercher un gestionnaire valide, appelez Intent.resolveActivity(). Vous trouverez un exemple dans la section Prendre des photos simplement: prendre une photo avec l'application Appareil photo.

Partager des fichiers entre plusieurs profils

Chaque profil dispose de son propre espace de stockage de fichiers. Étant donné qu'un URI de fichier fait référence à un emplacement spécifique dans le stockage de fichiers, cela signifie qu'un URI de fichier valide sur un profil ne l'est pas sur l'autre. Ce n'est généralement pas un problème pour une application, qui accède simplement aux fichiers qu'elle crée. Toutefois, si une application associe un fichier à un intent, il n'est pas prudent de joindre un URI de fichier, car dans certaines circonstances, l'intent peut être géré au niveau de l'autre profil. Par exemple, un administrateur d'appareil peut spécifier que les événements de capture d'image doivent être gérés par l'application d'appareil photo sur le profil personnel. Si l'intent est déclenché par une application sur le profil géré, l'appareil photo doit pouvoir écrire l'image à un emplacement où les applications du profil géré peuvent la lire.

Par sécurité, lorsque vous devez joindre un fichier à un intent pouvant passer d'un profil à l'autre, vous devez créer et utiliser un URI de contenu pour ce fichier. Pour en savoir plus sur le partage de fichiers avec des URI de contenu, consultez Partager des fichiers. Par exemple, l'administrateur de l'appareil peut autoriser l'appareil photo à gérer ACTION_IMAGE_CAPTURE dans le profil personnel. Le EXTRA_OUTPUT de l'intent de déclenchement doit contenir un URI de contenu spécifiant l'emplacement de stockage de la photo. L'application d'appareil photo peut écrire l'image à l'emplacement spécifié par cet URI, et l'application qui a déclenché l'intent peut lire ce fichier, même si elle se trouve sur l'autre profil.

Android 5.0 supprime la prise en charge des widgets de l'écran de verrouillage. Elle continue à prendre en charge les widgets sur l'écran d'accueil.