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 à
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 uneIllegalStateException
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 appelerContext.startForegroundService()
même lorsque l'application est en arrière-plan. Cependant, l'application doit appeler la méthodestartForeground()
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 commanderequestPinShortcut()
de la classeShortcutManager
. ACTION_CREATE_SHORTCUT
intent peut désormais créer des raccourcis d'application que vous gérez à l'aide deShortcutManager
. Cet intent peut aussi créer les anciens raccourcis du lanceur d'applications qui n'interagissent pasShortcutManager
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èreACTION_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 deShortcutManager
. - 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 exceptionNullPointerException
. 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 leView
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 laandroid:defaultFocusHighlightEnabled
pourfalse
dans le fichier XML de mise en page contenant lesView
, ou transmettezfalse
à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
-
- La
getSaveFormData()
renvoie désormaisfalse
. Auparavant, cette méthode renvoyaittrue
à la place. - Appel en cours
setSaveFormData()
non n'a plus d'effet.
- La
WebViewDatabase
-
- Appel en cours
clearFormData()
non n'a plus d'effet. - La
hasFormData()
méthode renvoie désormaisfalse
. Auparavant, cette méthode renvoyaittrue
lorsque le formulaire contenait des données.
- Appel en cours
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 votreView
les objets utilisent. Si TalkBack ne reconnaît toujours pas les gestes effectués sur cesView
objets, remplacerperformAccessibilityAction()
- Les services d'accessibilité connaissent désormais toutes
ClickableSpan
instances dans le ObjetsTextView
.
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êteContent-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
enhttp://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:
- La valeur de l'ancien paramètre
INSTALL_NON_MARKET_APPS
est maintenant toujours 1. Pour déterminer si une source inconnue peut installer des applications à l'aide de l'élément programme d'installation du package, utilisez plutôt la valeur renvoyée parcanRequestPackageInstalls()
- Si vous essayez de
changer la valeur
INSTALL_NON_MARKET_APPS
utilisantsetSecureSetting()
etUnsupportedOperationException
est générée. Pour empêcher les utilisateurs d'installer des applications inconnues sources, vous devez plutôt appliquerDISALLOW_INSTALL_UNKNOWN_SOURCES
utilisateur ou d'une restriction d'accès. -
Les profils gérés créés sur des appareils équipés d'Android 8.0 (niveau d'API 26) disposent automatiquement du
DISALLOW_INSTALL_UNKNOWN_SOURCES
utilisateur ou la restriction activée. Pour les profils gérés existants sur les appareils mis à niveau vers Android 8.0, leDISALLOW_INSTALL_UNKNOWN_SOURCES
utilisateur est activée automatiquement, à moins que le propriétaire du profil n'ait explicitement désactivé cette restriction (avant la mise à niveau) en définissantINSTALL_NON_MARKET_APPS
sur 1.
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 valeurANDROID_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
.
-
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
- 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)
etsomeMethod(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'objetWebView
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
etnet.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 unNetworkRequest
ouNetworkCallback
. 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écessiteREAD_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'APILauncherApps
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 pasonAudioFocusChange()
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'argumentstreamType
de la classeAudioTrack
), 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>
- 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.
- 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.
- 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. - 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 appelerCollections.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 deList
, évitez de remplacersort()
Si une classe parente implémente
sort()
de manière inappropriée, généralement possible de remplacerList.sort()
avec une implémentation basée surList.toArray()
,Arrays.sort()
etListIterator.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, commesortCompat()
, au lieu de remplacersort()
-
Collections.sort()
est désormais comptabilisé comme une modification structurelle Répertoriez les implémentations qui appellentsort()
. Par exemple, dans les versions la plate-forme antérieure à Android 8.0 (niveau d'API 26), avec des itérations unArrayList
et en appelantsort()
au milieu de l’itération aurait généré uneConcurrentModificationException
si le tri a été effectué en appelantList.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.