Changements de comportement dans Android 8.0

En plus des nouvelles fonctionnalités, Android 8.0 (niveau d'API 26) 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.

La plupart de ces changements concernent toutes les applications, quelle que soit la version Android qu'ils ciblent. Toutefois, plusieurs modifications ne concernent que le ciblage par applications Android 8.0 Pour plus de clarté, cette est divisée en deux sections: Modifications pour toutes les applications et Modifications pour le ciblage des applications Android 8.0

Modifications pour toutes les applications

Ces changements de comportement s'appliquent à toutes les applications lorsqu'elles s'exécutent sur la plate-forme Android 8.0 (niveau d'API 26), niveau d'API ciblé. Tous les développeurs doivent examiner ces changements et de modifier leurs applications pour les prendre en charge correctement, le cas échéant.

Limites d'exécution en arrière-plan

L'une des modifications apportées par Android 8.0 (niveau d'API 26) améliorer l'autonomie de la batterie lorsque votre application entre dans en cache (aucun composants, le système libère tous les wakelocks détenus par l'application.

De plus, pour améliorer les performances de l'appareil, le système limite certaines des applications qui ne s'exécutent pas au premier plan. Plus spécifiquement :

  • Le degré de liberté des applications exécutées en arrière-plan est désormais limité ils peuvent accéder aux services d'arrière-plan.
  • Les applications ne peuvent pas utiliser leur fichier manifeste pour s'enregistrer pour la plupart des diffusions implicites (c'est-à-dire les diffusions qui ne ciblent pas spécifiquement l'application).

Par défaut, ces restrictions ne s'appliquent qu'aux applications qui ciblent O. Toutefois, les utilisateurs peuvent activer ces restrictions pour n'importe quelle application à partir de l'écran Paramètres, même si l'application n'a pas ciblé O.

Android 8.0 (niveau d'API 26) inclut également les modifications suivantes apportées à des méthodes spécifiques:

  • La méthode startService() génère désormais une IllegalStateException si une application ciblant Android 8.0 tente d'utiliser cette méthode dans une situation où il n'est pas autorisé de créer des services d'arrière-plan.
  • La nouvelle méthode Context.startForegroundService() lance une service de premier plan. Le système autorise les applis pour appeler Context.startForegroundService() même lorsque l'application est en arrière-plan. Cependant, l'application doit appeler la méthode startForeground() de ce service dans les cinq secondes après la création du service.

Pour en savoir plus, consultez Limites d'exécution en arrière-plan.

Limites de localisation en arrière-plan Android

Afin de préserver la batterie, l'expérience utilisateur et l'état du système, les applications en arrière-plan reçoivent les mises à jour de la position moins fréquemment lorsqu'elles sont utilisées sur un appareil équipés d'Android 8.0. Ce changement de comportement affecte toutes les applications qui reçoivent des notifications de position, y compris les services Google Play.

Ces modifications affectent les API suivantes:

  • Fused Location Provider (FLP)
  • Géorepérage
  • Mesures GNSS
  • Gestionnaire d'établissements
  • Gestionnaire Wi-Fi

Pour vous assurer que votre application s'exécute comme prévu, procédez comme suit:

  • Examinez la logique de votre application et assurez-vous d'utiliser la dernière position API.
  • Vérifier que votre application présente le comportement attendu pour chaque utilisation .
  • Envisagez d'utiliser le Fusion un fournisseur de localisation (FLP, Location Provider) ou un géorepérage pour gérer les cas d'utilisation qui dépendent la position actuelle de l'utilisateur.

Pour en savoir plus sur ces modifications, consultez Localisation en arrière-plan Limites.

Raccourcis d'application

Android 8.0 (niveau d'API 26) inclut les modifications suivantes apportées aux raccourcis d'application:

  • Le numéro de diffusion com.android.launcher.action.INSTALL_SHORTCUT n'a aucune incidence sur votre application, car elle est désormais privée, implicite annonce. Créez plutôt un raccourci d'application à l'aide de la commande requestPinShortcut() de la classe ShortcutManager.
  • ACTION_CREATE_SHORTCUT intent peut désormais créer des raccourcis d'application que vous gérez à l'aide de ShortcutManager. Cet intent peut aussi créer les anciens raccourcis du lanceur d'applications qui n'interagissent pas ShortcutManager Auparavant, cet intent pouvait créer uniquement les anciens raccourcis du lanceur d'applications.
  • Raccourcis créés avec requestPinShortcut() et les raccourcis créés dans une activité qui gère ACTION_CREATE_SHORTCUT sont désormais des raccourcis d'application à part entière. Par conséquent, les applications peuvent désormais les mettre à jour à l'aide des méthodes de ShortcutManager.
  • Les anciens raccourcis conservent leurs fonctionnalités des versions précédentes de Android, mais vous devez les convertir manuellement en raccourcis d'application dans votre application.

Pour en savoir plus sur les modifications apportées aux raccourcis d'application, consultez les Épingler des raccourcis et Widgets.

Paramètres régionaux et internationalisation

Android 7.0 (niveau d'API 24) a introduit le concept de capacité à spécifier des paramètres régionaux par défaut pour la catégorie, mais certaines API continuaient à utiliser le Locale.getDefault() générique , sans arguments, alors qu'ils auraient dû utiliser les paramètres régionaux par défaut de la catégorie DISPLAY. Dans Android 8.0 (niveau d'API 26), Les méthodes suivantes utilisent désormais Locale.getDefault(Category.DISPLAY) au lieu de Locale.getDefault():

Locale.getDisplayScript(Locale) également revient à Locale.getDefault() lorsque Valeur displayScript spécifiée pour Locale n'est pas disponible.

D'autres modifications liées aux paramètres régionaux et à l'internationalisation ce qui suit:

  • L'appel de Currency.getDisplayName(null) génère une exception NullPointerException. correspondant au comportement documenté.
  • L'analyse du nom du fuseau horaire a été modifiée. Auparavant, Les appareils Android ont utilisé la valeur de l'horloge système échantillonnée au démarrage Temps nécessaire pour mettre en cache les noms des fuseaux horaires utilisés pour l'analyse de la date fois. L'analyse pourrait donc être affectée si le système l'horloge était incorrecte au démarrage ou dans d'autres cas plus rares.

    Dans les cas courants, la logique d'analyse utilise la bibliothèque ICU et la valeur actuelle de l'horloge système lors de l'analyse des noms de fuseau horaire. Ce la modification fournit des résultats plus corrects, qui peuvent différer des précédents Versions d'Android lorsque votre application utilise des classes telles que SimpleDateFormat

  • Android 8.0 (niveau d'API 26) met à jour la version de la bibliothèque ICU vers la version 58.

Fenêtres d'alerte

Si une application utilise SYSTEM_ALERT_WINDOW et utilise l'un des types de fenêtres suivants pour tenter d'afficher fenêtres d'alerte au-dessus des autres fenêtres d'applications et du système:

...alors elles apparaissent toujours sous les fenêtres qui utilisent le TYPE_APPLICATION_OVERLAY fenêtre de mots clés. Si une application cible Android 8.0 (niveau d'API 26), elle utilise l'attribut TYPE_APPLICATION_OVERLAY le type de fenêtre pour afficher les fenêtres d'alerte.

Pour en savoir plus, consultez la section Types de fenêtres courants pour fenêtres d'alerte dans les changements de comportement des applications ciblant Android 8.0.

Saisie et navigation

Avec l'arrivée des applications Android sur ChromeOS et d'autres grands facteurs de forme, comme les tablettes, nous constatons un retour à l'utilisation du clavier Applications Android. Dans Android 8.0 (niveau d'API 26), nous avons procédé à un nouveau traitement à l'aide de le clavier en tant que périphérique d'entrée de navigation, ce qui offre une expérience prévisible pour la navigation par flèches et par onglets.

En particulier, nous avons apporté les modifications suivantes au ciblage des éléments, comportement:

  • Si vous n'avez pas défini de couleur d'état de focus pour un objet View (de premier plan ou d'arrière-plan) drawable), le framework définit désormais une couleur de mise en surbrillance par défaut pour le View Cette mise en surbrillance est un drawable ondulant en fonction du thème de l'activité.

    Si vous ne souhaitez pas qu'un objet View utilise cette valeur par défaut mettre en surbrillance l'élément sélectionné, définissez la android:defaultFocusHighlightEnabled pour false dans le fichier XML de mise en page contenant les View, ou transmettez false à setDefaultFocusHighlightEnabled() dans la logique d'UI de votre application.

  • Pour tester l'impact de la saisie au clavier sur le focus de l'élément d'interface utilisateur, vous pouvez activer Dessin > Afficher les contours de la mise en page pour les développeurs. Sur Android 8.0, cette option affiche un "X" une icône sur l'élément qui a actuellement le focus.

De plus, tous les éléments de la barre d'outils sous Android 8.0 sont automatiquement clusters de navigation au clavier ce qui permet aux utilisateurs de naviguer plus facilement dans chaque barre d'outils dans son ensemble.

Pour en savoir plus sur la façon d'améliorer la prise en charge de la navigation au clavier dans votre application, consultez les Ressources Navigation avec le clavier.

Saisie automatique de formulaires Web

Maintenant que la fonctionnalité Saisie automatique d'Android Framework permet d'utiliser la fonctionnalité de saisie automatique, Les méthodes suivantes associées aux objets WebView ont été modifiées Pour les applications installées sur des appareils équipés d'Android 8.0 (niveau d'API 26):

WebSettings
WebViewDatabase
  • Appel en cours clearFormData() non n'a plus d'effet.
  • La hasFormData() méthode renvoie désormais false. Auparavant, cette méthode renvoyait true lorsque le formulaire contenait des données.

Accessibilité

Android 8.0 (niveau d'API 26) inclut les modifications d'accessibilité suivantes:

  • Le framework d'accessibilité convertit désormais tous les gestes de double appui en ACTION_CLICK actions. TalkBack peut alors se comporter comme les autres services d'accessibilité.

    Si les objets View de votre application utilisent un écran tactile personnalisé vérifiez qu'ils fonctionnent toujours avec TalkBack. Vous pourriez Il vous suffit d'enregistrer le gestionnaire de clics que votre View les objets utilisent. Si TalkBack ne reconnaît toujours pas les gestes effectués sur ces View objets, remplacer performAccessibilityAction()

  • Les services d'accessibilité connaissent désormais toutes ClickableSpan instances dans le Objets TextView.

Pour savoir comment rendre votre application plus accessible, consultez Accessibilité.

Mise en réseau et connectivité HTTP(S)

Android 8.0 (niveau d'API 26) inclut les modifications de comportement suivantes concernant réseau et de la connectivité HTTP(S) :

  • Les requêtes OPTIONS sans corps ont un Content-Length: 0 en-tête. Auparavant, elles ne comportaient pas d'en-tête Content-Length.
  • HttpURLConnection normalise les URL contenant des chemins d'accès vides en ajoutant une barre oblique après le nom d'hôte ou d'autorité par une barre oblique. Par exemple, il peut convertit http://example.com en http://example.com/
  • Un sélecteur de proxy personnalisé défini via ProxySelector.setDefault() cible uniquement l'adresse (schéma, hôte et port) d'une URL demandée. Par conséquent, la sélection du proxy peut uniquement être basée sur ces valeurs. Une URL transmis à un sélecteur de proxy personnalisé n'inclut pas l'URL demandée un chemin d'accès, des paramètres de requête ou des fragments.
  • Les URI ne peuvent pas contenir d'étiquettes vides.

    Auparavant, la plate-forme proposait une solution de contournement pour accepter les étiquettes vides dans d'hôte, ce qui est une utilisation illégale des URI. Cette solution de contournement Compatibilité avec les anciennes versions de libcore. Développeurs utilisant l'API verrait à tort le message ADB : "URI example.com comporte des libellés vides dans le nom d'hôte. Ce format est incorrect et ne sera plus accepté sur les futurs appareils Android de sortie. » Android 8.0 supprime cette solution de contournement. le système renvoie "null" pour les URI dont le format est incorrect

  • Implémentation de HttpsURLConnection sur Android 8.0 n'effectue pas de remplacement de version de protocole TLS/SSL non sécurisé.
  • La gestion des connexions HTTP(S) par tunnel a été modifiée comme suit: <ph type="x-smartling-placeholder">
      </ph>
    • Lors de la tunnelisation d'une connexion HTTPS, le système place correctement le numéro de port (:443) dans la ligne d'hôte lors de l'envoi ces informations à un serveur intermédiaire. Auparavant, le port numéro apparaît uniquement sur la ligne CONNECT.
    • Le système n'envoie plus d'user-agent ni d'autorisation de proxy en-têtes d'une requête acheminée par tunnel vers le serveur proxy.

      Le système n'envoie plus d'en-tête "proxy-Authorization" à Http(s)URLConnection acheminée par tunnel au proxy lors de la configuration à l'aide du tunnel. Au lieu de cela, le système génère un en-tête d'autorisation proxy, et l'envoie au proxy lorsque celui-ci envoie HTTP 407 en réponse à la requête initiale.

      De même, le système ne copie plus l'en-tête user-agent. de la requête acheminée par tunnel à la requête proxy qui configure le à l'aide du tunnel. À la place, la bibliothèque génère un en-tête user-agent pour requête.

  • send(java.net.DatagramPacket) génère une SocketException si la méthode connect() précédemment exécutée a échoué.
    • DatagramSocket.connect() définit une "pendingSocketException" s'il existe une erreur interne. Avant Android 8.0, une fonction recv() ultérieure a généré une SocketException même si un appel send() aurait réussi. Par souci de cohérence, les deux appels génèrent désormais une SocketException.
  • InetAddress.isReachable() tente d'utiliser le protocole ICMP avant de revenir à TCP Echo. standard.
    • Certains hôtes qui bloquent le port 7 (TCP Echo), tels que google.com, peuvent deviennent accessibles s'ils acceptent le protocole ICMP Echo.
    • Pour les hôtes vraiment inaccessibles, ce changement signifie que deux fois plus avant le retour de l'appel.

Bluetooth

Android 8.0 (niveau d'API 26) apporte les modifications suivantes à la longueur de les données que le ScanRecord.getBytes() récupère:

  • La méthode getBytes() n'émet aucune hypothèse concernant le nombre d'octets reçus. Par conséquent, les applications ne doivent pas s'appuyer sur nombre minimal ou maximal d'octets renvoyés. Il doit plutôt évaluer la longueur du tableau obtenu.
  • Les appareils compatibles avec le Bluetooth 5 peuvent renvoyer des données dont la durée dépasse la précédent maximum d'environ 60 octets.
  • moins de 60 octets si un appareil distant ne fournit pas de réponse d'analyse. peut également être renvoyé.

Connectivité fluide

Android 8.0 (niveau d'API 26) apporte un certain nombre d'améliorations aux paramètres Wi-Fi pour faciliter le choix le réseau Wi-Fi qui offre la meilleure expérience utilisateur. Voici les modifications apportées:

  • Amélioration de la stabilité et de la fiabilité.
  • Une interface utilisateur plus lisible et plus intuitive.
  • Un menu unique et consolidé des préférences Wi-Fi.
  • Sur les appareils compatibles, activation automatique du Wi-Fi lorsqu'un réseau enregistré de haute qualité se trouve à proximité.

Sécurité

Android 8.0 inclut les fonctionnalités de sécurité modifications:

  • La plate-forme n'est plus compatible avec SSLv3.
  • Lors de l'établissement d'une connexion HTTPS vers un serveur qui n'est pas met en œuvre la négociation de version du protocole TLS, HttpsURLConnection ne tente plus la solution de contournement de revenir à des versions antérieures du protocole TLS et de nouvelles tentatives.
  • Android 8.0 (niveau d'API 26) applique une couche de sécurité (SECCOMP) filtrer pour afficher toutes les applications. La liste des appels système autorisés se limite à ces exposées par bionique. Bien qu'il existe plusieurs autres appels système pour des raisons de rétrocompatibilité, nous vous déconseillons de les utiliser.
  • Les objets WebView de votre application s'exécutent désormais en multiprocessus . Le contenu Web est géré dans un processus isolé et distinct du processus contenant le processus de l'application pour renforcer la sécurité.
  • Vous ne pouvez plus supposer que les APK se trouvent dans des répertoires dont le nom se termine dans -1 ou -2. Les applications doivent utiliser sourceDir pour obtenir la répertoire, et ne vous fiez pas directement au format du répertoire.
  • Pour en savoir plus sur les améliorations de sécurité liées à l'utilisation consultez la section Bibliothèques natives.

En outre, Android 8.0 (niveau d'API 26) introduit les modifications suivantes liées à l'installation applications inconnues provenant de sources inconnues:

Pour en savoir plus sur l'installation d'applications inconnues, consultez les Application inconnue Guide des autorisations d'installation.

Pour obtenir des consignes supplémentaires sur la sécurisation de votre application, consultez Sécurité pour les développeurs Android

Confidentialité

Android 8.0 (niveau d'API 26) rend les fonctionnalités suivantes sur la plate-forme.

  • La plate-forme gère désormais les identifiants différemment.
    • Pour les applications installées avant la mise à jour OTA vers une version de Android 8.0 (niveau d'API 26) (niveau d'API 26), la valeur ANDROID_ID reste inchangé sauf si elle est désinstallée, puis réinstallée après l'OTA. Pour conserver les valeurs les désinstallations après l’OTA, les développeurs peuvent associer les anciennes et les nouvelles valeurs à l’aide de <ph type="x-smartling-placeholder"></ph> Sauvegarde clé-valeur.
    • Pour les applications installées sur un appareil équipé d'Android 8.0, la valeur de Le champ d'application de ANDROID_ID est maintenant défini par clé de signature d'application et par utilisateur. La valeur ANDROID_ID est unique pour chaque combinaison de clé de signature d'application, d'utilisateur et d'appareil. Par conséquent, les applications avec des clés de signature différentes s'exécutant sur le même appareil ne voient plus le même ID Android (même pour le même utilisateur).
    • La valeur de ANDROID_ID ne change pas lors de la désinstallation ou de la réinstallation du package, tant que le la clé de signature est la même (et l'application n'a pas été installée avant une OTA vers version d'Android 8.0).
    • La valeur de ANDROID_ID ne change pas même si une mise à jour du système entraîne la modification de la clé de signature du package.
    • Sur les appareils livrés avec les services Google Play et l'identifiant publicitaire, vous devez utiliser <ph type="x-smartling-placeholder"></ph> Identifiant publicitaire. Un système simple et standard pour monétiser les applications L'identifiant publicitaire est un identifiant publicitaire unique et réinitialisable par l'utilisateur. Il est fourni par les services Google Play.

      Les autres fabricants doivent continuer pour fournir ANDROID_ID.

  • Interroger la propriété système net.hostname génère une valeur résultat.

Journalisation des exceptions non interceptées

Si une application installe un Thread.UncaughtExceptionHandler qui fait sans appeler la Thread.UncaughtExceptionHandler par défaut, le système fait ne pas arrêter l'application lorsqu'une exception non détectée se produit. À partir de Android 8.0 (niveau d'API 26), le système enregistre la trace de la pile d'exceptions dans ce la situation ; dans les versions précédentes de la plate-forme, le système a consigné la trace de la pile d'exception.

Nous vous recommandons d'utiliser des Thread.UncaughtExceptionHandler personnalisés les implémentations appellent toujours le gestionnaire par défaut. les applications qui suivent cette recommandation ne sont pas concernées par le changement d'Android 8.0.

Modification de la signature findViewById()

Toutes les instances de la méthode findViewById() renvoient désormais <T extends View> T au lieu de View. Cette modification a les conséquences suivantes:

  • Par conséquent, le code existant peut maintenant présenter un type renvoyé ambigu. par exemple, s'il existe à la fois someMethod(View) et someMethod(TextView), qui transmet le résultat d'un appel à findViewById()
  • Lorsque vous utilisez le langage source Java 8, cela nécessite une conversion explicite en View lorsque le type renvoyé n'est pas limité (par exemple, assertNotNull(findViewById(...)).someViewMethod())
  • Remplacements des méthodes findViewById() non finales (pour exemple, Activity.findViewById()) ont besoin de leur retour type mis à jour.

Modification des statistiques d'utilisation du fournisseur de contacts

Dans les versions précédentes d'Android, le composant Contacts Provider permet aux développeurs d'obtenir les données d'utilisation de chaque contact. Ces données d'utilisation présente des informations pour chaque adresse e-mail et chaque numéro de téléphone associé avec un contact, y compris le nombre de fois où il a été contacté et la dernière fois que le contact a été contacté. Les applications qui demandent le READ_CONTACTS peut lire ces données.

Les applications peuvent toujours lire ces données si elles le demandent READ_CONTACTS l'autorisation. Sur Android 8.0 (niveau d'API 26) ou version ultérieure, les requêtes de données d'utilisation renvoient des approximations et non des valeurs exactes. Le système Android gère les valeurs exactes en interne. Cette modification n'affecte donc pas de saisie semi-automatique Google.

Ce changement de comportement affecte les paramètres de requête suivants:

Gestion des collections

AbstractCollection.removeAll() et AbstractCollection.retainAll() génère toujours une NullPointerException. auparavant, les NullPointerException n'a pas été généré lors de la collecte de vide. Ce changement rend le comportement cohérent avec la documentation.

Android Enterprise

Android 8.0 (niveau d'API 26) modifie la le comportement de certaines API et fonctionnalités des applications d'entreprise, y compris concernant les appareils des outils de contrôle des règles (DPC). Voici les modifications apportées:

  • Nouveaux comportements pour aider les applications à prendre en charge les profils professionnels sur les appareils entièrement gérés.
  • Modifications apportées à la gestion des mises à jour du système, à la vérification des applications et à l'authentification pour améliorer l'intégrité des appareils et du système.
  • Améliorations apportées à l'expérience utilisateur pour le provisionnement, les notifications, Écran "Récents" et VPN permanent.

Pour découvrir toutes les modifications apportées aux entreprises dans Android 8.0 (niveau d'API 26) et en savoir plus affecter votre application, consultez la section Android dans l'entreprise

Applications ciblant Android 8.0

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

Fenêtres d'alerte

Applications qui utilisent le SYSTEM_ALERT_WINDOW l'autorisation ne peut plus utiliser les types de fenêtres suivants pour afficher les fenêtres d'alerte au-dessus des autres applications et fenêtres système:

À la place, les applications doivent utiliser un nouveau type de fenêtre appelé TYPE_APPLICATION_OVERLAY

Lorsque vous utilisez la TYPE_APPLICATION_OVERLAY fenêtre pour afficher les fenêtres d'alerte de votre application, conservez les caractéristiques suivantes du nouveau type de fenêtre:

  • Les fenêtres d'alerte d'une application apparaissent toujours sous les fenêtres système critiques, telles que comme la barre d'état et les IME.
  • Le système peut déplacer ou redimensionner les fenêtres qui utilisent le TYPE_APPLICATION_OVERLAY type de fenêtre pour améliorer la présentation de l'écran.
  • En ouvrant le volet des notifications, les utilisateurs peuvent accéder aux paramètres pour bloquer un l'application d'afficher les fenêtres d'alerte affichées à l'aide de la TYPE_APPLICATION_OVERLAY type de fenêtre.

Notifications de modification du contenu

Android 8.0 (niveau d'API 26) modifie la façon dont ContentResolver.notifyChange() et registerContentObserver(Uri, boolean, ContentObserver) se comportent pour les applications ciblant Android 8.0.

Ces API nécessitent désormais qu'un ContentProvider valide est défini pour l'autorité dans tous les URI. Définir un ContentProvider valide avec les autorisations appropriées protéger votre application contre les modifications de contenu provenant d'applications malveillantes et vous empêcher de la fuite de données potentiellement privées à des applications malveillantes.

Afficher le focus

Désormais, les objets View cliquables peuvent également être sélectionnés par par défaut. Si vous souhaitez qu'un objet View soit cliquable, mais pas sélectionnable, définissez la <ph type="x-smartling-placeholder"></ph> android:focusable à false dans la mise en page Fichier XML contenant View, ou transmettez false sur setFocusable() dans l'interface utilisateur de votre application. logique.

Mise en correspondance user-agent dans la détection du navigateur

Android 8.0 (niveau d'API 26) ou version ultérieure inclut la chaîne d'identifiant de compilation OPR. Certaines correspondances de schéma peuvent la logique de détection des navigateurs n'identifie pas à tort un navigateur non-Opera comme Opera. Voici un exemple de correspondance de structure:

if(p.match(/OPR/)){k="Opera";c=p.match(/OPR\/(\d+.\d+)/);n=new Ext.Version(c[1])}

Pour éviter tout problème lié à une identification erronée, utilisez une chaîne autre que OPR en tant que correspondance de schéma pour le navigateur Opera.

Sécurité

Les modifications suivantes affectent la sécurité dans Android 8.0 (niveau d'API 26):

  • Si la configuration de la sécurité réseau de votre application options ne prend plus en charge le trafic en texte clair, Les objets WebView ne peuvent pas accéder aux sites Web via HTTP. Chaque L'objet WebView doit utiliser HTTPS à la place.
  • Le paramètre système Autoriser les sources inconnues a été supprimé. dans sa l'autorisation Installation d'applis inconnues gère les installations d'applis inconnues provenant de sources inconnues. Pour en savoir plus sur cette nouvelle autorisation, consultez les Application inconnue Guide des autorisations d'installation.

Pour obtenir des consignes supplémentaires sur la sécurisation de votre application, consultez Sécurité pour les développeurs Android

Accès au compte et visibilité

Sous Android 8.0 (niveau d'API 26), les applications ne peuvent plus y accéder aux comptes d'utilisateurs, sauf si l'authentificateur est le propriétaire des comptes ou l'utilisateur accorde cet accès. La Autorisation GET_ACCOUNTS ne suffit plus. Pour pouvoir accéder à un compte, les applications doivent utiliser AccountManager.newChooseAccountIntent() ou à un authentificateur spécifique . Après avoir accès aux comptes, une application peut appeler AccountManager.getAccounts() pour y accéder.

Abandon d'Android 8.0 LOGIN_ACCOUNTS_CHANGED_ACTION Applications doit plutôt utiliser addOnAccountsUpdatedListener() pour obtenir des informations sur les comptes pendant l'exécution.

Pour en savoir plus sur les nouvelles API et méthodes ajoutées pour l'accès au compte et visibilité, consultez la section Accès au compte et la visibilité dans la section "Nouvelles API" de ce document.

Confidentialité

Les modifications suivantes affectent la confidentialité dans Android 8.0 (niveau d'API 26).

  • Les propriétés système net.dns1, net.dns2 net.dns3 et net.dns4 ne sont plus est un changement qui améliore la confidentialité sur la plate-forme.
  • Pour obtenir des informations réseau telles que les serveurs DNS, les applications avec l'/le/la ACCESS_NETWORK_STATE l'autorisation peut enregistrer un NetworkRequest ou NetworkCallback. Ces classes sont disponibles sur Android 5.0 (niveau d'API 21) ou version ultérieure.
  • Build.SERIAL est obsolète. Les applications qui ont besoin de connaître le numéro de série du matériel doivent à la place utilisez la nouvelle méthode Build.getSerial(), qui nécessite READ_PHONE_STATE l'autorisation.
  • L'API LauncherApps n'autorise plus le profil professionnel applications pour obtenir des informations sur le profil principal. Lorsqu'un utilisateur se trouve dans l'API LauncherApps se comporte comme si aucune application sont installés dans d'autres profils du même groupe de profils ; Comme précédemment, les tentatives d'accès à des profils non liés entraînent des SecurityExceptions.

Autorisations

Avant Android 8.0 (niveau d'API 26), si une application demandait une autorisation au moment de l'exécution et que l'autorisation a été accordée, le système a accordé à l'application le reste des autorisations groupe d'autorisations et celles qui ont été enregistrées dans le fichier manifeste.

Pour les applications ciblant Android 8.0, ce comportement sont corrigées. L'application ne se voit accorder que les autorisations dont elle dispose explicitement demandée. Cependant, une fois que l'utilisateur a donné son autorisation à l'application, toutes les demandes ultérieures d'autorisations dans ce groupe automatiquement accordé.

Par exemple, supposons qu'une application répertorie à la fois READ_EXTERNAL_STORAGE et WRITE_EXTERNAL_STORAGE dans son fichier manifeste. L'application demande READ_EXTERNAL_STORAGE et l'utilisateur l'accorde. Si l'application cible un niveau d'API 25 ou inférieur, le système accorde WRITE_EXTERNAL_STORAGE en parallèle car il appartient au même groupe d'autorisations STORAGE enregistrées dans le fichier manifeste. Si l'application cible Android 8.0 (niveau d'API 26), le système accorde seulement READ_EXTERNAL_STORAGE à ce moment-là ; Toutefois, si l'application demande WRITE_EXTERNAL_STORAGE par la suite, le système accorde ce privilège sans demander à l'utilisateur.

Contenus multimédias

  • Le framework peut effectuer diminution automatique du volume par elle-même. Dans ce cas, lorsqu'une autre application demande à sélectionner AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK, l'application ciblée réduit son volume, mais ne reçoit généralement pas onAudioFocusChange() et n'effectuera pas ne sera plus au premier plan sur le son. De nouvelles API sont disponibles pour remplacer ce comportement des applications qui doivent s’interrompre au lieu de s’atténuer.
  • Lorsque l'utilisateur répond à un appel téléphonique, le son du flux multimédia actif est coupé pendant .
  • Toutes les API liées à l'audio doivent utiliser AudioAttributes plutôt que par type de flux audio pour décrire le cas d'utilisation de la lecture audio. Continuez à utiliser les types de flux audio uniquement pour les commandes de volume. Les autres types de flux continuent d'être utilisés (par exemple, l'argument streamType de la classe AudioTrack), mais le système l'enregistre en tant qu'erreur.
  • Lorsque vous utilisez un AudioTrack, si l'application demande un tampon audio suffisamment volumineux, essaie d'utiliser la sortie du tampon profond, si elle est disponible.
  • Dans Android 8.0 (niveau d'API 26), le traitement des événements de boutons multimédias est différent: <ph type="x-smartling-placeholder">
      </ph>
    1. Gestion des boutons multimédias dans une activité de l'interface utilisateur n'a pas changé: les activités de premier plan sont toujours traitées en priorité les événements de bouton multimédia.
    2. Si l'activité de premier plan ne gère pas l'événement du bouton multimédia, le système achemine l'événement à l'application qui a lu en local le dernier contenu audio. État actif, indicateurs et lecture l'état d'une session multimédia ne sont pas pris en compte pour déterminer quelle application reçoit des contenus multimédias les événements de bouton.
    3. Si la session multimédia de l'application a été publiée, le système envoie l'événement du bouton multimédia MediaButtonReceiver s'il y en a une.
    4. Dans tous les autres cas, le système ignore l'événement du bouton multimédia.

Bibliothèques natives

Dans les applications ciblant Android 8.0 (niveau d'API 26), les bibliothèques natives ne chargement plus long s'ils contiennent un segment de charge à la fois accessible en écriture et exécutable. En raison de ce changement, certaines applications risquent de ne plus fonctionner si elles ont dont les segments de chargement sont incorrects. Il s'agit d'un de renforcement de la sécurité.

Pour plus d'informations, voir Segments accessibles en écriture et exécutables.

Les modifications apportées à Linker sont liées au niveau d'API ciblé par une application. S'il y a une modification de l'éditeur de liens niveau d'API ciblé, l'application ne peut pas charger la bibliothèque. Si vous ciblez un niveau d'API inférieur à celui où la modification de l'éditeur de liens se produit, Logcat affiche un avertissement.

Gestion des collections

Sous Android 8.0 (niveau d'API 26), Collections.sort() est implémenté sur en haut de List.sort(). L'inverse était vrai sous Android 7.x (niveaux d'API 24 et 25): L'implémentation par défaut de List.sort() appelée Collections.sort().

Cette modification permet à Collections.sort() pour profiter des List.sort() optimisées implémentations standards, mais présente les contraintes suivantes:

  • Implémentations de List.sort() ne doit pas appeler Collections.sort(), car cela entraînerait un dépassement de pile en raison d'une récursion infinie. Si vous préférez le comportement par défaut dans votre implémentation de List, évitez de remplacer sort()

    Si une classe parente implémente sort() de manière inappropriée, généralement possible de remplacer List.sort() avec une implémentation basée sur List.toArray(), Arrays.sort() et ListIterator.set() Exemple : 

    @Override
public void sort(Comparator<? super E> c) {
  Object[] elements = toArray();
  Arrays.sort(elements, c);
  ListIterator<E> iterator = (ListIterator<Object>) listIterator();
  for (Object element : elements) {
    iterator.next();
    iterator.set((E) element);
  }
}

    Dans la plupart des cas, vous pouvez également remplacer List.sort() avec un qui délègue à différentes applications en fonction du niveau d'API. Exemple : 

    @Override
public void sort(Comparator<? super E> comparator) {
  if (Build.VERSION.SDK_INT <= 25) {
    Collections.sort(this);
  } else {
    super.sort(comparator);
  }
}

    Si vous n'utilisez ces deux méthodes que pour avoir un sort() disponible à tous les niveaux d'API, envisagez de lui donner un nom unique, comme sortCompat(), au lieu de remplacer sort()

  • Collections.sort() est désormais comptabilisé comme une modification structurelle Répertoriez les implémentations qui appellent sort(). Par exemple, dans les versions la plate-forme antérieure à Android 8.0 (niveau d'API 26), avec des itérations un ArrayList et en appelant sort() au milieu de l’itération aurait généré une ConcurrentModificationException si le tri a été effectué en appelant List.sort(). Collections.sort() n'a pas généré d'exception.

    Ce changement rend le comportement de la plate-forme plus cohérent : se traduit désormais par un ConcurrentModificationException.

Comportement de chargement des classes

Android 8.0 (niveau d'API 26) vérifie que les chargeurs de classe ne briser les hypothèses de l'environnement d'exécution lors du chargement de nouvelles classes. Ces vérifications sont si la classe est référencée à partir de Java (à partir de forName()), bytecode Dalvik, ou JNI. La plate-forme n'intercepte pas les appels directs de Java vers loadClass() et ne la vérifie pas. les résultats de ces appels. Ce comportement ne devrait pas affecter le bon fonctionnement des chargeurs de classe.

La plate-forme vérifie que le descripteur de la classe renvoyé par le chargeur de classe correspond au descripteur attendu. Si le descripteur renvoyé ne correspond pas, la plate-forme génère une erreur NoClassDefFoundError et stocke l'exception, un message détaillé notant l'écart.

La plate-forme vérifie également que les descripteurs des classes demandées sont valides. Ce "check" détecte les appels JNI qui chargent indirectement des classes telles que GetFieldID(), en transmettant des descripteurs non valides à ces classes. Par exemple, un champ avec la signature java/lang/String est introuvable, car cette signature n'est pas valide. il devrait s'agir de Ljava/lang/String;.

Ceci est différent d'un appel JNI à FindClass(). où java/lang/String est un nom complet valide.

Android 8.0 (niveau d'API 26) ne permet pas d'essayer plusieurs chargeurs de classe pour définir des classes à l'aide du même objet DexFile. Si vous tentez de le faire, l'environnement d'exécution Android générera une exception InternalError s'affiche avec le message "Tenter d'enregistrer le fichier dex <filename>" avec plusieurs chargeurs de classe".

L'API DexFile étant désormais obsolète, nous vous recommandons vivement d'utiliser L'un des classloaders de la plate-forme, y compris PathClassLoader ou BaseDexClassLoader.

Remarque : Vous pouvez créer plusieurs chargeurs de classe qui font référence à le même conteneur APK ou JAR à partir du système de fichiers. Cette opération n'a normalement pas entraîner une surcharge de mémoire importante: si les fichiers DEX du conteneur sont stockés au lieu compressées, la plate-forme peut effectuer une opération mmap sur ces éléments plutôt que les extraire directement. Cependant, si la plateforme doit extraire le fichier DEX du conteneur, référencer un fichier DEX de cette manière peut consommer beaucoup de mémoire.

Dans Android, tous les chargeurs de classe sont considérés comme compatibles en parallèle. Lorsque plusieurs threads se lancent en concurrence pour charger la même classe avec la même classe loader, le premier thread à terminer l'opération l'emporte, et le résultat est utilisé pour dans les autres threads. Ce comportement se produit, que le composant Loader de classe soit ou non a renvoyé la même classe, a renvoyé une classe différente ou a généré une exception. La plate-forme ignore ces exceptions en mode silencieux.

Attention : Dans les versions de la plate-forme à une version antérieure à Android 8.0 (niveau d'API 26), le fait de contourner ces hypothèses peut conduire à définir la même plusieurs fois, la corruption du tas de mémoire en raison de la confusion de la classe, et d'autres effets indésirables.