Changements de comportement dans Android 7.0

En plus des nouvelles fonctionnalités et capacités, Android 7.0 comprend divers changements de comportement au niveau du système et des API. Ce document met en évidence certains des changements clés que vous devez comprendre et tenir compte dans vos applications.

Si vous avez déjà publié une application pour Android, sachez qu'elle peuvent être affectés par ces changements sur la plate-forme.

Batterie et mémoire

Android 7.0 inclut des modifications de comportement du système visant à améliorer l'autonomie de la batterie d'appareils et la réduction de l'utilisation de la RAM. Ces changements peuvent affecter l'accès de votre application aux ressources système, ainsi que la manière dont votre application interagit avec d'autres applications via certains intents implicites.

Sommeil

Introduit dans Android 6.0 (niveau d'API 23), la fonctionnalité Sommeil améliore l'autonomie de la batterie de reportant les activités du processeur et du réseau lorsqu'un utilisateur laisse un appareil débranché, à l'arrêt et avec l'écran éteint. Android 7.0 vous offre encore plus de possibilités Améliorations apportées à la fonctionnalité Sommeil en appliquant un sous-ensemble de restrictions de processeur et de réseau lorsque l'appareil est débranché avec l'écran éteint, mais pas nécessairement immobile, par exemple lorsqu'un appareil mobile se déplace dans la poche d'un utilisateur.

Illustration de la façon dont la fonctionnalité Sommeil applique un premier niveau de
  restrictions d'activité du système pour améliorer l'autonomie de la batterie

Figure 1 : Illustration de la façon dont la fonctionnalité Sommeil applique un premier niveau de les restrictions d’activité du système afin d’améliorer l’autonomie de la batterie.

Lorsqu'un appareil est sur batterie et que l'écran est éteint depuis un certain temps l'appareil passe en mode Sommeil et applique le premier sous-ensemble de restrictions : désactive l'accès au réseau des applications, et reporte les tâches et les synchronisations. Si l'appareil est à l'arrêt pendant un certain temps après l'activation du mode Sommeil, le système applique le reste des restrictions de la fonctionnalité Sommeil pour PowerManager.WakeLock, Alarmes AlarmManager, recherches GPS et réseaux Wi-Fi. Indépendamment de que certaines ou toutes les restrictions Sommeil soient appliquées, le système active le appareil pendant de courtes périodes de maintenance durant lesquelles les applications sont autorisées un accès réseau et peut exécuter tout job/synchronisation différé.

Illustration de la façon dont la fonctionnalité Sommeil applique un deuxième niveau de
  restrictions d'activité du système une fois que l'appareil est à l'arrêt pendant un certain temps

Figure 2. Illustration de la façon dont la fonctionnalité Sommeil applique un deuxième niveau de les restrictions d'activité du système une fois que l'appareil est à l'arrêt pendant un certain temps.

Lorsque vous activez l'écran ou branchez l'appareil, vous quittez le mode Sommeil et supprime ces restrictions de traitement. Ce comportement supplémentaire affectent les recommandations et les bonnes pratiques pour adapter votre application version de Sommeil introduite dans Android 6.0 (niveau d'API 23), comme indiqué dans <ph type="x-smartling-placeholder"></ph> Optimisation pour les fonctionnalités Sommeil et Mise en veille des applications Vous devez toujours suivez ces recommandations, par exemple en utilisant Firebase Cloud Messaging (FCM) pour d'envoyer et de recevoir des messages, et de planifier les mises à jour pour vous adapter un comportement supplémentaire du mode Sommeil.

Projet Svelte: optimisations en arrière-plan

Android 7.0 supprime trois diffusions implicites afin d'optimiser les deux l'utilisation de la mémoire et la consommation d'énergie. Cette modification est nécessaire car les couches implicites annonces lancent fréquemment des applications qui se sont inscrites pour les écouter en arrière-plan. La suppression de ces annonces peut s'avérer très bénéfique pour l'appareil les performances et l'expérience utilisateur.

La connectivité des appareils mobiles change fréquemment, par exemple lorsqu'ils sont en mouvement entre le Wi-Fi et les données mobiles. Actuellement, les applications peuvent surveiller les modifications la connectivité en enregistrant un récepteur pour la diffusion CONNECTIVITY_ACTION implicite dans sa fichier manifeste. Étant donné que de nombreuses applications s'inscrivent pour recevoir cette annonce, une seule un commutateur réseau peut les faire tous activer et traiter la diffusion à une seule fois.

De même, dans les versions précédentes d'Android, les applications pouvaient s'inscrire pour recevoir des annonces ACTION_NEW_PICTURE et ACTION_NEW_VIDEO implicites d'autres applications, telles que Caméra. Lorsqu'un utilisateur prend une photo avec l'application Appareil photo, ces applications s'activent. pour traiter la diffusion.

Pour atténuer ces problèmes, Android 7.0 applique les d'optimisation:

  • Les applications ciblant Android version 7.0 (niveau 24 d'API) et ultérieures ne reçoivent pas les diffusions CONNECTIVITY_ACTION s'ils déclarent leur récepteur de diffusion dans le fichier manifeste. Les applications continueront à recevoir des diffusions CONNECTIVITY_ACTION si elles enregistrent leur BroadcastReceiver auprès de Context.registerReceiver() et que ce contexte est toujours valide.
  • Le système n'envoie plus d'annonces ACTION_NEW_PICTURE ni ACTION_NEW_VIDEO. Cette optimisation affecte toutes les applications, pas seulement celles qui ciblent Android 7.0.

Si votre appli utilise l'un de ces intents, vous devez supprimer les dépendances dès que possible, afin de cibler correctement les appareils Android 7.0. Le framework Android fournit plusieurs solutions pour atténuer le besoin ces diffusions implicites. Par exemple, l'API JobScheduler fournit un mécanisme robuste pour planifier des opérations réseau lorsque les conditions spécifiées, telles que la connexion à un réseau illimité sont remplis. Vous pouvez même utiliser JobScheduler pour réagir aux modifications apportées aux fournisseurs de contenu.

Pour en savoir plus sur les optimisations en arrière-plan dans Android 7.0 (niveau d'API), 24) et comment adapter votre application, consultez la section Arrière-plan Optimisations.

Modifications des autorisations

Android 7.0 apporte des modifications aux autorisations qui peuvent affecter votre application.

Modifications des autorisations du système de fichiers

Afin d'améliorer la sécurité des fichiers privés, le répertoire privé des les applications ciblant Android 7.0 ou version ultérieure ont un accès limité (0700). Ce paramètre empêche la fuite des métadonnées des fichiers privés, comme leur taille. ou de leur existence. Cette modification d'autorisation a plusieurs effets secondaires:

Partager des fichiers entre des applications

Pour les applications ciblant Android 7.0, le framework Android applique La règle d'API StrictMode qui interdit l'exposition des URI file:// en dehors de votre application. Si un intent contenant un URI de fichier quitte votre application, celle-ci échoue avec une exception FileUriExposedException.

Pour partager des fichiers entre des applications, vous devez envoyer un URI content://. et accorder une autorisation d'accès temporaire à l'URI. Le moyen le plus simple d'accorder cette autorisation est de à l'aide de la classe FileProvider. Pour en savoir plus, sur les autorisations et le partage de fichiers, consultez la page Partager des fichiers.

Améliorations liées à l'accessibilité

Android 7.0 inclut des modifications destinées à améliorer la convivialité du pour les utilisateurs malvoyants. Ces modifications devraient ne nécessitent généralement pas de modifications du code de votre application, mais vous devez ces fonctionnalités et les tester avec votre application pour évaluer leur impact potentiel sur les utilisateurs expérience.

Zoom sur l'écran

Android 7.0 permet aux utilisateurs de définir la taille d'affichage, qui agrandit ou réduit tous les éléments de l'écran, améliorant ainsi l'accessibilité de l'appareil pour les utilisateurs malvoyants. Les utilisateurs ne peuvent pas zoomer sur l'écran au-delà d'une limite minimale largeur de sw320dp, qui correspond à la largeur d'un Nexus 4, un téléphone de taille moyenne couramment utilisé.

Écran affichant la taille d&#39;affichage sans zoom d&#39;un appareil exécutant une image système Android 7.0
Écran montrant l&#39;augmentation de la taille d&#39;affichage d&#39;un appareil exécutant une image système Android 7.0

Figure 3. L'écran de droite montre l'effet pour augmenter la taille d'affichage d'un appareil exécutant une image système Android 7.0.

Lorsque la densité de l'appareil change, le système notifie les applications en cours d'exécution dans le de différentes manières:

  • Si une application cible un niveau d'API 23 ou inférieur, le système se ferme automatiquement. tous ses processus en arrière-plan. Cela signifie que si un utilisateur quitte une application de ce type pour ouvrir l'écran Settings (Paramètres) et modifier le paramètre Taille d'affichage, le système ferme l'application qu'en cas de mémoire insuffisante. Si l'application a un premier plan processus, le système informe ces processus du changement de configuration décrits dans la section Manipulation Modifications apportées à l'environnement d'exécution, comme si l'orientation de l'appareil avait changé.
  • Si une application cible Android 7.0, tous ses processus (premier plan et arrière-plan) sont informés du changement de configuration décrits dans la section Manipulation Modifications apportées à l'environnement d'exécution.

La plupart des applications n'ont pas besoin d'apporter de modifications pour prendre en charge cette fonctionnalité, à condition les applications respectent les bonnes pratiques Android. Points spécifiques à vérifier:

  • Tester votre application sur un appareil avec une largeur d'écran de sw320dp et vous assurer qu'elle fonctionne correctement.
  • Lorsque la configuration de l'appareil change, mettez à jour les paramètres les informations mises en cache, telles que les bitmaps mis en cache ou les ressources chargées à partir du réseau. Rechercher des modifications de configuration lorsque l'application reprend à partir de l'état mis en pause de l'état.

    Remarque:Si vous mettez en cache des données dépendantes de la configuration, il s'agit d'un il est conseillé d'inclure des métadonnées pertinentes, telles que l'écran approprié ou la densité en pixels de ces données. L'enregistrement de ces métadonnées vous permet de : décider si vous devez actualiser les données mises en cache après une configuration ; le changement.

  • Évitez de spécifier des dimensions en px, car elles n'effectuent pas la mise à l'échelle avec comme la densité de l'écran. Spécifiez plutôt des dimensions avec des valeurs indépendantes de la densité pixels (dp).

Paramètres Vision dans l'assistant de configuration

Android 7.0 inclut des paramètres visuels sur l'écran d'accueil, qui permet aux utilisateurs configurez les paramètres d'accessibilité suivants sur un nouvel appareil: Geste d'agrandissement, Taille de la police, Taille d'affichage et TalkBack. Cette modification augmente la visibilité des bugs liés aux différents paramètres de l'écran. À évaluez l'impact de cette fonctionnalité, testez vos applications avec ces paramètres activés. Vous trouverez ces paramètres sous Paramètres > Accessibilité.

Association des applications du NDK aux bibliothèques de la plate-forme

À partir d'Android 7.0, le système empêche les applications de s'associer dynamiquement contre les bibliothèques non NDK, ce qui peut entraîner le plantage de votre application. Ce changement dans vise à créer une expérience cohérente dans l'application lors des mises à jour de la plate-forme. et différents appareils. Même si votre code ne contient pas de lien bibliothèques privées, il est possible qu'une bibliothèque statique tierce application pourrait le faire. Par conséquent, tous les développeurs doivent vérifier afin que leurs applications ne plantent pas sur les appareils équipés d'Android 7.0. Si votre application utilise code natif, vous ne devez utiliser que des API NDK publiques.

Votre application peut tenter d'accéder à une plate-forme privée de trois façons différentes API:

  • Votre application accède directement aux bibliothèques de plates-formes privées. Vous devez mettre à jour votre application pour inclure sa propre copie de ces bibliothèques ou utiliser les API NDK publiques.
  • Votre application utilise une bibliothèque tierce qui accède à une plate-forme privée bibliothèques. Même si vous êtes certain que votre application n'a pas accès à des bibliothèques privées vous devez quand même tester votre application dans ce scénario.
  • Votre application fait référence à une bibliothèque qui n'est pas incluse dans son APK. Pour exemple, cela peut se produire si vous avez essayé d’utiliser votre propre copie d’OpenSSL, mais oublié de l'intégrer à l'APK de votre application ; L'appli peut s'exécuter normalement sur les versions de la plate-forme Android, y compris libcrypto.so. Cependant, l'application pourrait planter sur les versions ultérieures d'Android qui n'incluent pas cette bibliothèque (par exemple, Android 6.0 et versions ultérieures). Pour résoudre ce problème, assurez-vous de regrouper tous vos bibliothèques non NDK avec votre APK.

Les applications ne doivent pas utiliser de bibliothèques natives qui ne sont pas incluses dans le NDK, car ils peuvent changer ou être supprimés d’une version à l’autre d’Android. La passer d’OpenSSL à BoringSSL en est un exemple. Par ailleurs, car il n'existe aucune exigence de compatibilité pour les bibliothèques de plate-forme. inclus dans le NDK, différents appareils peuvent offrir différents niveaux de et la compatibilité avec d'autres appareils.

Afin de réduire l'impact que cette restriction peut avoir sur applications publiées, un ensemble de bibliothèques dont l'utilisation est importante, comme libandroid_runtime.so, libcutils.so libcrypto.so et libssl.so sont temporairement accessible sur Android 7.0 (niveau d'API 24) pour les applications ciblant le niveau d'API 23 ou moins élevée. Si votre application charge l'une de ces bibliothèques, Logcat génère un avertissement. et un toast s'affiche sur l'appareil cible pour vous en informer. Si ces vous devez mettre à jour votre application pour inclure sa propre copie de ces ou n'utilisez que les API NDK publiques. Prochaines versions d'Android peut limiter l'utilisation des bibliothèques privées l'application peut planter.

Toutes les applications génèrent une erreur d'exécution lorsqu'elles appellent une API qui n'est ni publics ni temporairement accessibles. Résultat : System.loadLibrary et dlopen(3) reviennent tous les deux NULL, et peut entraîner le plantage de votre application. Nous vous recommandons de vérifier code d'application pour supprimer l'utilisation d'API de plate-forme privée et tester minutieusement vos applications à l'aide d'un appareil ou d'un émulateur exécutant Android 7.0 (niveau d'API 24) ; Si vous utilisez vous n'êtes pas certain que votre application utilise des bibliothèques privées, vous pouvez consulter Logcat pour identifier l'erreur d'exécution.

Le tableau suivant décrit le comportement attendu d'une en fonction de son utilisation des bibliothèques natives privées et de son API cible niveau (android:targetSdkVersion).

Bibliothèques Niveau d'API cible Accès à l'environnement d'exécution via l'éditeur de liens dynamique Comportement d'Android 7.0 (niveau d'API 24) Comportement futur de la plate-forme Android
NDK public Tout Accessible Fonctionne comme prévu Fonctionne comme prévu
Privées (bibliothèques privées accessibles temporairement) 23 ou inférieure Temporairement accessible Fonctionne comme prévu, mais vous recevez un avertissement Logcat. Erreur d'exécution
Privées (bibliothèques privées accessibles temporairement) 24 ou ultérieure Restricted (Limité) Erreur d'exécution Erreur d'exécution
Privé (autre) Tout Restricted (Limité) Erreur d'exécution Erreur d'exécution

Vérifier si votre application utilise des bibliothèques privées

Pour vous aider à identifier les problèmes de chargement des bibliothèques privées, logcat peut générer une un avertissement ou une erreur d'exécution. Par exemple, si votre application cible le niveau d'API 23 ou une version antérieure et tente d'accéder à une bibliothèque privée sur un appareil équipé d'Android 7.0, un avertissement semblable au suivant peut s'afficher:

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

Ces avertissements Logcat vous indiquent quelle bibliothèque tente d'accéder de plate-forme privée, mais ne fera pas planter votre application. Si l'application cible le niveau d'API 24 ou supérieur, mais Logcat génère erreur d'exécution et votre application peut planter:

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by
"/system/lib/libnativeloader.so" is not accessible for the namespace
"classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

Vous pouvez également voir ces sorties logcat si votre application utilise des bibliothèques tierces qui se connectent de manière dynamique aux API de la plate-forme privée. L'outil Readelf Android 7.0DK vous permet de générer une liste de toutes les ressources partagées d'un fichier .so donné en exécutant la commande suivante:

aarch64-linux-android-readelf -dW libMyLibrary.so

Mettre à jour votre appli

Voici quelques étapes à suivre pour corriger ce type d'erreur assurez-vous que votre application ne plante pas lors des futures mises à jour de la plate-forme:

  • Si votre application utilise des bibliothèques de plate-forme privées, vous devez la mettre à jour pour inclure sa propre copie de ces bibliothèques ou utilisez les API NDK publiques.
  • Si votre application utilise une bibliothèque tierce qui accède à des symboles privés, contactez l'auteur de la bibliothèque pour la mettre à jour.
  • Assurez-vous d'empaqueter toutes vos bibliothèques non NDK avec votre APK.
  • Utilisez les fonctions JNI standards au lieu de getJavaVM. getJNIEnv de libandroid_runtime.so:
    AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
    AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
    JavaVM::AttachCurrentThread from <jni.h>.
    
  • Utilisez __system_property_get à la place du property_get privé. symbole issu de libcutils.so. Pour ce faire, utilisez __system_property_get. comprenant les éléments suivants:
    #include <sys/system_properties.h>
    

    Remarque:La disponibilité et le contenu des propriétés système sont non testés via CTS. Une meilleure solution serait d'éviter d'utiliser ces vos propriétés.

  • Utilisez une version locale du symbole SSL_ctrl à partir de libcrypto.so. Par exemple, vous devez associer libcyrpto.a de manière statique dans votre fichier .so, ou inclure une version associée de libcrypto.so de façon dynamique à partir de BoringSSL/OpenSSL et en empaquetant-la dans votre APK.

Android for Work

Android 7.0 comporte des modifications pour les applications qui ciblent Android for Work, y compris modifications apportées à l'installation du certificat, réinitialisation du mot de passe, utilisateur secondaire gestion et accès aux identifiants des appareils. Si vous créez des applications pour dans les environnements Android for Work, nous vous recommandons de passer en revue votre application en conséquence.

  • Vous devez installer un programme d’installation de certificat délégué avant que le DPC puisse définir Pour les applications de propriétaire de profil et d'appareil ciblant Android 7.0 (niveau d'API 24), vous devez installer le programme d’installation du certificat délégué avant appels de contrôleur (DPC) DevicePolicyManager.setCertInstallerPackage() Si le programme d'installation n'est pas encore installé, le système génère une IllegalArgumentException
  • Les restrictions de réinitialisation de mot de passe pour les administrateurs d'appareils s'appliquent désormais au profil propriétaires. Les administrateurs de l'appareil ne peuvent plus utiliser DevicePolicyManager.resetPassword() pour effacer les mots de passe ou les modifier celles qui sont déjà définies. Les administrateurs d'appareils peuvent toujours définir un mot de passe, mais seulement si l'appareil ne dispose d'aucun mot de passe, code ou schéma.
  • Les propriétaires d'appareils et de profils peuvent gérer les comptes même si les restrictions sont défini. Les propriétaires d'appareils et de profils peuvent appeler les API Account Management même si des restrictions utilisateur DISALLOW_MODIFY_ACCOUNTS sont en place.
  • Les propriétaires d'appareils peuvent gérer plus facilement les utilisateurs secondaires. Lorsqu’un appareil est s'exécutant en mode propriétaire de l'appareil, la restriction DISALLOW_ADD_USER est définie automatiquement. Cela empêche les utilisateurs de créer des instances secondaires non gérées utilisateurs. De plus, les CreateUser() et Les méthodes createAndInitializeUser() sont obsolètes. le nouveau La méthode DevicePolicyManager.createAndManageUser() les remplace.
  • Les propriétaires d'appareils peuvent accéder aux identifiants des appareils. Le propriétaire d'un appareil peut y accéder Adresse MAC Wi-Fi d'un appareil, en utilisant DevicePolicyManager.getWifiMacAddress() Si le Wi-Fi n'a jamais été activée sur l'appareil, cette méthode renvoie la valeur null.
  • Le paramètre "Mode Travail" contrôle l'accès aux applications professionnelles. Lorsque le mode Travail est désactivé, lanceur système indique que les applications professionnelles ne sont pas disponibles en les grisant. Activation... permet à nouveau de rétablir son comportement normal.
  • Lors de l'installation d'un fichier PKCS #12 contenant une chaîne de certificats client et la clé privée correspondante dans l'interface utilisateur des paramètres, le certificat CA dans n'est plus installée dans le stockage des identifiants de confiance. Cela fait n'a pas d'incidence sur le résultat de KeyChain.getCertificateChain() lorsque les applications tentent de récupérer le client de la chaîne de certificats. Si nécessaire, le certificat CA doit être installé. séparément dans l'espace de stockage des identifiants de confiance via l'interface utilisateur des paramètres, format codé DER sous une extension de fichier .crt ou .cer.
  • À partir d'Android 7.0, l'enregistrement et le stockage des empreintes digitales sont gérés. par utilisateur. Si le client DPC (Device Policy Client) d'un propriétaire de profil cible un niveau d'API 23 (ou version antérieure) sur un appareil équipé d'Android 7.0 (niveau d'API 24), l'utilisateur est définir une empreinte digitale sur l'appareil, mais les applications professionnelles ne peuvent pas accéder à l'empreinte de l'appareil. Lorsque l'outil DPC cible le niveau d'API 24 ou supérieur, l'utilisateur peut définir l'empreinte digitale pour le profil professionnel en accédant à Paramètres > Sécurité > Sécurité du profil professionnel
  • Un nouvel état de chiffrement ENCRYPTION_STATUS_ACTIVE_PER_USER est renvoyé par DevicePolicyManager.getStorageEncryptionStatus(), à indiquent que le chiffrement est actif et que la clé de chiffrement est liée utilisateur. Le nouvel état n'est renvoyé que si l'outil DPC cible le niveau d'API 24 ou supérieur. Pour les applications ciblant des niveaux d'API antérieurs, ENCRYPTION_STATUS_ACTIVE est renvoyée, même si la clé de chiffrement est spécifique à l'utilisateur ou au profil.
  • Dans Android 7.0, plusieurs méthodes qui affectent normalement l'ensemble le comportement de l'appareil est différent si un profil professionnel est installé avec un un défi professionnel séparé. Au lieu d'affecter l'ensemble de l'appareil, s'appliquent uniquement au profil professionnel. (Vous trouverez la liste complète de ces méthodes dans la documentation DevicePolicyManager.getParentProfileInstance().) Par exemple : DevicePolicyManager.lockNow() verrouille uniquement le profil professionnel, au lieu de le verrouillage de l’ensemble de l’appareil. Pour chacune de ces méthodes, vous pouvez récupérer en appelant la méthode sur l'instance parente du DevicePolicyManager; vous pouvez obtenir ce parent en Appel de DevicePolicyManager.getParentProfileInstance() en cours. Par exemple, si vous appelez lockNow() de l'instance parente , l'appareil est entièrement verrouillé.

Conservation des annotations

Android 7.0 corrige un bug qui empêchait la visibilité des annotations. Ce problème a permis à l'environnement d'exécution d'accéder à des annotations alors qu'il n'aurait pas dû en mesure de le faire. Ces annotations comprenaient:

  • VISIBILITY_BUILD: destiné à n'être visible qu'au moment de la compilation.
  • VISIBILITY_SYSTEM: est destiné à être visible au moment de l'exécution, mais uniquement système sous-jacent.

Si votre application a eu recours à ce comportement, veuillez ajouter une règle de conservation aux annotations qui doivent être disponibles au moment de l'exécution. Pour ce faire, utilisez @Retention(RetentionPolicy.RUNTIME).

Modifications de la configuration TLS/SSL par défaut

Android 7.0 apporte les modifications suivantes à la configuration TLS/SSL par défaut utilisé par les applications pour le trafic HTTPS et TLS/SSL:

  • Les suites de chiffrement RC4 sont désormais désactivées.
  • Les suites de chiffrement CHACHA20-POLY1305 sont désormais activées.

La désactivation par défaut de RC4 peut entraîner des dysfonctionnements dans HTTPS ou TLS/SSL la connectivité lorsque le serveur ne négocie pas les suites de chiffrement modernes. La solution privilégiée consiste à améliorer la configuration du serveur afin de permettre ainsi que des suites et des protocoles de chiffrement plus modernes. Idéalement, TLSv1.2 et AES-GCM doit être activée, et les suites de chiffrement de confidentialité persistante (ECDHE) doivent à activer et à privilégier.

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

Remarque:Ces modifications ne concernent pas WebView.

Applications ciblant Android 7.0

Ces changements de comportement ne s'appliquent qu'aux applications qui ciblent Android 7.0 (niveau d'API 24) ou version ultérieure Les applications compilées avec Android 7.0 ou si vous définissez targetSdkVersion sur Android 7.0 ou version ultérieure, vous devez modifier leurs applications afin de prendre en charge ces comportements correctement, le cas échéant.

Modifications apportées à la sérialisation

Android 7.0 (niveau d'API 24) a corrigé un bug dans le calcul des valeurs par défaut serialVersionUID où elle ne correspondait pas à la spécification.

Classes qui implémentent Serializable et ne pas spécifier de champ serialVersionUID explicite pourrait voient une modification de leur SerialVersionUID par défaut, ce qui entraînerait une exception généré lors de la tentative de désérialisation des instances de la classe sérialisées sur une version antérieure ou par une application ciblant une version antérieure version. Le message d'erreur ressemblera à ceci:

local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567

Pour résoudre ces problèmes, vous devez ajouter un champ serialVersionUID à Toute classe concernée avec la valeur stream classdesc serialVersionUID issue du message d'erreur (par exemple, 1234 po dans ce cas. Cette modification est conforme à toutes les recommandations de bonnes pratiques l'écriture du code de sérialisation et fonctionne sur toutes les versions d'Android.

Le bug spécifique qui a été corrigé était lié à la présence de balises méthodes d'initialisation (par exemple, <clinit>). Selon le la présence ou l'absence d'une méthode d'initialisation statique dans aura une incidence sur le serialVersionUID par défaut calculé pour cette classe. Avant la correction du bug, le calcul contrôlait également la super-classe pour une initialiseur statique si une classe n'en avait pas.

Pour rappel, ce changement n'affecte pas les applications qui ciblent les niveaux d'API 23 ou les classes comportant un champ serialVersionUID ou les classes qui disposent d'une méthode d'initialisation statique.

Autres points importants

  • Lorsqu'une application s'exécute sous Android 7.0, mais cible un niveau d'API inférieur, et que l'utilisateur change de taille d'affichage, le processus de l'application est arrêté. L'application doit pouvoir gérer ce scénario de façon optimale. Sinon, il plante. lorsque l'utilisateur la restaure à partir de "Récents".

    Vous devez tester votre application pour vous assurer que ce comportement ne se produit pas. Pour ce faire, vous risquez de provoquer un plantage lors de la fermeture manuelle de l'application via DCM.

    Les applications ciblant Android 7.0 (niveau d'API 24) ou version ultérieure ne sont pas automatiquement appliquées sont supprimées en cas de changement de densité. mais il est possible qu'ils réagissent mal les modifications de configuration.

  • Les applications sous Android 7.0 doivent pouvoir gérer correctement les modifications de configuration, et ne doit pas planter lors des démarrages suivants. Vous pouvez vérifier le comportement de l'application en modifiant la taille de la police (Paramètre > Affichage > Taille de la police), puis restaurer l'application depuis Récents.
  • En raison d'un bug dans les versions précédentes d'Android, le système n'a pas écrit d'indicateurs à un socket TCP sur le thread principal en tant que violation du mode strict. Android 7.0 corrige ce bug. Les applications qui présentent ce comportement génèrent désormais une android.os.NetworkOnMainThreadException. En général, effectuer des opérations réseau sur le thread principal est une mauvaise idée, car ces opérations présentent généralement une latence élevée provoquant des ANR et des à-coups.
  • La famille de méthodes Debug.startMethodTracing() est désormais définie par défaut sur stocker la sortie dans votre répertoire spécifique au package sur le stockage partagé, et non au niveau supérieur de la carte SD. Cela signifie que les applis n'ont plus besoin de demander l'autorisation WRITE_EXTERNAL_STORAGE pour utiliser ces API.
  • De nombreuses API de plate-forme ont maintenant commencé à vérifier si des charges utiles volumineuses sont envoyées. dans les transactions Binder, et le système affiche à nouveau TransactionTooLargeExceptions en tant que RuntimeExceptions, au lieu de les journaliser ou de les supprimer en mode silencieux. Un un exemple courant est le stockage d'une trop grande quantité de données Activity.onSaveInstanceState(), ce qui provoque ActivityThread.StopInfo une RuntimeException lorsque votre application cible Android 7.0.
  • Si une application publie des tâches Runnable dans un View, et le View n'est pas attachée à une fenêtre, le système met la tâche Runnable en file d'attente avec View ; la tâche Runnable ne s'exécute que lorsque le View est associé à une fenêtre. Ce comportement corrige les bugs suivants: <ph type="x-smartling-placeholder">
      </ph>
    • Si une application a publié sur un View à partir d'un fil de discussion autre que celui prévu thread UI de la fenêtre, Runnable risque donc de s'exécuter sur le mauvais thread.
    • Si la tâche Runnable a été publiée depuis un fil de discussion autre que un thread looper, l'application peut exposer la tâche Runnable.
  • Si une application sur Android 7.0 avec DELETE_PACKAGES l’autorisation tente de supprimer un package, mais une autre application avait installé ce package, le système a besoin d'une confirmation de l'utilisateur. Dans ce scénario, les applications doivent s'attendre STATUS_PENDING_USER_ACTION comme l'état renvoyé lorsqu'ils appellent PackageInstaller.uninstall()
  • Le fournisseur JCA appelé Crypto est obsolète, car il ne peut SHA1PRNG, est cryptographiquement faible. Les applis ne peuvent plus utiliser SHA1PRNG pour dériver (de manière non sécurisée) les clés, car ce fournisseur n'est plus disponibles. Pour en savoir plus, consultez le blog publier Security "Crypto" fournisseur obsolète dans Android N.