Changements de comportement : toutes les applications

Android 10 inclut des modifications de comportement susceptibles d'affecter votre application. Les modifications indiquées sur cette page s'appliquent à votre appli lorsqu'elle est en cours d'exécution sur Android 10, quelle que soit la targetSdkVersion de l'application. Vous devez tester votre application et la modifier si nécessaire pour prendre en charge ces changements correctement.

Si la targetSdkVersion de votre application est 29 ou ultérieure, vous devez également pour permettre d'autres modifications. Veillez à lire les modifications de comportement pour les applications "29".

Restrictions des interfaces hors SDK

Pour garantir la stabilité et la compatibilité des applications, la plate-forme a commencé à restreindre les interfaces non SDK que votre application peut utiliser sous Android 9 (niveau d'API 28). Android 10 inclut les listes mises à jour d'interfaces non SDK limitées grâce à la collaboration avec des développeurs Android et les derniers tests internes. Notre objectif est de nous assurer des alternatives sont disponibles avant de limiter les interfaces non SDK.

Si vous ne ciblez pas Android 10 (niveau d'API 29), certaines de ces modifications pourrait ne pas vous affecter immédiatement. Toutefois, même si vous pouvez actuellement utiliser certaines Des interfaces non SDK (en fonction du niveau d'API cible de votre application) l'utilisation d'un champ ou d'une méthode non SDK présente toujours un risque élevé de casser votre l'application.

Si vous n'êtes pas sûr que votre application utilise des interfaces non SDK, vous pouvez tester votre application pour le savoir. Si votre application repose sur des interfaces non SDK, vous devriez commencer à planifier une la migration vers des alternatives SDK. Nous comprenons néanmoins que certaines applications ont des cas d'utilisation valides pour utiliser des interfaces non SDK. Si vous ne trouvez pas d'autre solution à l'utilisation d'une interface non SDK pour une fonctionnalité de votre application, vous devez demander une nouvelle API publique.

Pour en savoir plus, consultez Mises à jour des restrictions d'interface non SDK dans Android 10. et consultez la section Restrictions concernant les interfaces non SDK.

Navigation par gestes

À partir d'Android 10, les utilisateurs peuvent activer la navigation par gestes sur l'appareil. Si un utilisateur active la navigation par gestes, cela affecte toutes les applications du appareil, que l'application cible ou non le niveau d'API 29. Par exemple, si l'utilisateur balaie à partir du bord de l'écran, le système interprète ce geste comme la navigation, sauf si une application remplace spécifiquement ce geste pour une partie l'écran.

Pour que votre application soit compatible avec la navigation par gestes, vous devez étendre la le contenu de l'application d'un bord à l'autre, et gérez les gestes contradictoires de manière appropriée. Pour en savoir plus, consultez la section Navigation par gestes. dans la documentation Google Cloud.

NDK

Android 10 inclut les modifications suivantes du NDK.

Les objets partagés ne peuvent pas contenir de relocalisations de texte

Utilisation non autorisée d'Android 6.0 (niveau d'API 23) des transferts de texte dans des objets partagés. Le code doit être chargé tel quel et ne doit pas être modifiées. Cette modification améliore la sécurité et les temps de chargement des applications.

SELinux applique cette restriction aux applications qui ciblent Android 10 ou supérieur. Si ces applications continuent d'utiliser des objets partagés contenant du texte car ils risquent de ne plus fonctionner.

Modifications apportées aux bibliothèques Bionic et aux chemins d'accès dynamiques de l'éditeur de liens

À partir d'Android 10, plusieurs chemins sont des liens symboliques au lieu de les fichiers normaux. Applications qui utilisaient les chemins d'accès vers des fichiers normaux risque de ne plus fonctionner:

• /system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
• /system/lib/libm.so -> /apex/com.android.runtime/lib/bionic/libm.so
• /system/lib/libdl.so -> /apex/com.android.runtime/lib/bionic/libdl.so
• /system/bin/linker -> /apex/com.android.runtime/bin/linker

Ces modifications s'appliquent également aux variantes 64 bits du fichier, avec lib/ remplacé par lib64/.

Pour des raisons de compatibilité, les liens symboliques sont fournis dans les anciens chemins d'accès. Par exemple, /system/lib/libc.so est un lien symbolique vers /apex/com.android.runtime/lib/bionic/libc.so. Bref. dlopen(“/system/lib/libc.so”) continuera de fonctionner, mais les applis trouveront la différence lorsqu'ils essaient d'examiner les bibliothèques chargées en lisant /proc/self/maps ou une valeur similaire, ce qui n'est pas habituel, mais nous avons constaté que certaines applications le font dans le cadre de leur processus anti-piratage. Si c'est le cas, Les chemins d'accès /apex/… doivent être ajoutés en tant que chemins valides pour les fichiers Bionic.

Binaires/bibliothèques système mappés sur la mémoire d'exécution uniquement

À partir d'Android 10, les segments exécutables des binaires et des bibliothèques système sont mappés dans la mémoire en mode lecture seule (non lisible) en tant que technique de renforcement contre les attaques par réutilisation de code. Si votre application effectue des opérations de lecture segments de mémoire marqués comme étant en exécution uniquement, qu'il s'agisse d'un bug, d'une faille inspection intentionnelle de la mémoire : le système envoie un signal SIGSEGV à votre application.

Pour déterminer si ce comportement a causé un plantage, examinez les fichier tombstone dans /data/tombstones/. Plantage lié à l'exécution uniquement contient le message d'abandon suivant:

Cause: execute-only (no-read) memory access error; likely due to data in .text.

Pour contourner ce problème et effectuer des opérations telles que l'inspection de la mémoire, possible de marquer les segments d'exécution uniquement comme lus et exécutés en appelant mprotect() Toutefois, nous vous recommandons vivement de le définir de nouveau exécuter uniquement par la suite, car ce paramètre d'autorisation d'accès fournit pour protéger votre application et vos utilisateurs.

Sécurité

Android 10 inclut les modifications de sécurité suivantes.

TLS 1.3 activé par défaut

Sous Android 10 ou version ultérieure, TLS 1.3 est activé par défaut pour tous les connexions TLS. Voici quelques détails importants sur notre protocole TLS 1.3 implémentation:

• Les suites de chiffrement TLS 1.3 ne peuvent pas être personnalisées. L'algorithme de chiffrement TLS 1.3 compatible les suites sont toujours activées lorsque TLS 1.3 est activé. Toute tentative de désactivation en appelant setEnabledCipherSuites() est ignorée.
• Lorsque TLS 1.3 est négocié, HandshakeCompletedListener sont appelés avant que les sessions soient ajoutées au cache de session. (Dans TLS 1.2 et des autres versions précédentes, ces objets sont appelés après l'ajout des sessions dans le cache de session.
• Dans certains cas où les instances SSLEngine génèrent une exception SSLHandshakeException sur des versions antérieures d'Android, elles génèrent une exception SSLProtocolException sur Android 10 ou version ultérieure.
• Le mode 0-RTT n'est pas pris en charge.

Si vous le souhaitez, vous pouvez obtenir un SSLContext pour lequel TLS 1.3 est désactivé en appelant SSLContext.getInstance("TLSv1.2") Vous pouvez également activer ou désactiver des versions de protocole pour chaque connexion en procédant comme suit : appel de setEnabledProtocols() en cours sur un objet approprié.

Les certificats signés avec SHA-1 ne sont pas approuvés dans TLS

Sous Android 10, les certificats qui utilisent l'algorithme de hachage SHA-1 ne sont pas approuvés dans les connexions TLS. Les autorités de certification racine n'ont pas délivré ce certificat depuis 2016. De plus, elles ne sont plus approuvées dans Chrome ni dans les autres principaux navigateurs.

Toute tentative de connexion échoue si elle est destinée à un site présentant un à l'aide de SHA-1.

Modifications et améliorations du comportement de KeyChain

Certains navigateurs, tels que Google Chrome, permettent aux utilisateurs de choisir un certificat lorsqu'un Le serveur TLS envoie un message de demande de certificat dans le cadre d'un handshake TLS. À partir d'Android 10, les objets KeyChain respectent les émetteurs et les paramètres de spécification de clé lors de l'appel de KeyChain.choosePrivateKeyAlias() pour afficher une invite de sélection de certificat aux utilisateurs. En particulier, cette requête contiennent des choix qui ne respectent pas les spécifications du serveur.

Si aucun certificat sélectionnable par l'utilisateur n'est disponible, comme c'est le cas de certificats conformes aux spécifications du serveur ou un appareil ne dispose certificats installés, l’invite de sélection de certificat ne s’affiche pas du tout.

De plus, il n'est pas nécessaire, sous Android 10 ou version ultérieure, de disposer verrouillage de l'écran de l'appareil pour importer des clés ou des certificats CA dans un objet KeyChain.

Autres modifications apportées au protocole TLS et à la cryptographie

Plusieurs modifications mineures ont été apportées aux bibliothèques TLS et de cryptographie qui prend effet sous Android 10:

• Les algorithmes de chiffrement AES/GCM/NoPadding et ChaCha20/Poly1305/NoPadding des tailles de mémoire tampon précises à partir de getOutputSize().
• La suite de chiffrement TLS_FALLBACK_SCSV est omise des tentatives de connexion avec un protocole maximal TLS 1.2 ou supérieur. Grâce aux améliorations apportées au serveur TLS, nous vous déconseillons d'essayer un remplacement externe TLS. À la place, nous vous recommandons de vous fier à la négociation de version TLS.
• ChaCha20-Poly1305 est un alias de ChaCha20/Poly1305/NoPadding.
• Les noms d'hôte se terminant par un point ne sont pas considérés comme des noms d'hôte SNI valides.
• L'extension supported_signature_algorithms de CertificateRequest est respecté lors du choix d’une clé de signature pour les réponses de certificat.
• Les clés de signature opaques, comme celles d'Android Keystore, peuvent être utilisées avec Signatures RSA-PSS dans TLS.

Diffusions Wi-Fi Direct

Sur Android 10, les annonces suivantes liées au Wi-Fi Direct ne sont pas persistantes:

• WIFI_P2P_CONNECTION_CHANGED_ACTION
• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

Si votre application comptait recevoir ces annonces au moment de l'enregistrement, car qu'elles étaient persistantes, utilisez la méthode get() appropriée lors de l'initialisation pour obtenir les informations à la place.

Fonctionnalités Wi-Fi Aware

Android 10 est compatible pour faciliter la création de sockets TCP/UDP à l'aide de Wi-Fi Aware les chemins de données. Pour créer un socket TCP/UDP se connectant à un ServerSocket, le client l'appareil doit connaître l'adresse IPv6 et le port du serveur. Auparavant, devaient être communiqués hors bande, par exemple via le Bluetooth ou la couche Wi-Fi Aware 2 ou découvert en bande à l'aide d'autres protocoles, comme le mDNS. Avec Android 10, les informations peuvent être communiquées lors de la configuration du réseau.

Le serveur peut effectuer l'une des opérations suivantes:

• Initialisez un ServerSocket et définissez ou obtenez le port à utiliser.
• Spécifiez les informations sur le port dans la requête réseau Wi-Fi Aware.

L'exemple de code suivant montre comment spécifier des informations de port dans le cadre du requête réseau:

val ss = ServerSocket()
val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle)
  .setPskPassphrase("some-password")
  .setPort(ss.localPort)
  .build()

val myNetworkRequest = NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build()

ServerSocket ss = new ServerSocket();
WifiAwareNetworkSpecifier ns = new WifiAwareNetworkSpecifier
  .Builder(discoverySession, peerHandle)
  .setPskPassphrase(“some-password”)
  .setPort(ss.getLocalPort())
  .build();

NetworkRequest myNetworkRequest = new NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build();

Le client exécute ensuite une requête réseau Wi-Fi Aware pour obtenir les valeurs IPv6 et port fourni par le serveur:

val callback = object : ConnectivityManager.NetworkCallback() {
  override fun onAvailable(network: Network) {
    ...
  }
  
  override fun onLinkPropertiesChanged(network: Network,
      linkProperties: LinkProperties) {
    ...
  }

  override fun onCapabilitiesChanged(network: Network,
      networkCapabilities: NetworkCapabilities) {
    ...
    val ti = networkCapabilities.transportInfo
    if (ti is WifiAwareNetworkInfo) {
       val peerAddress = ti.peerIpv6Addr
       val peerPort = ti.port
    }
  }
  override fun onLost(network: Network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback)

callback = new ConnectivityManager.NetworkCallback() {
  @Override
  public void onAvailable(Network network) {
    ...
  }
  @Override
  public void onLinkPropertiesChanged(Network network,
      LinkProperties linkProperties) {
    ...
  }
  @Override
  public void onCapabilitiesChanged(Network network,
      NetworkCapabilities networkCapabilities) {
    ...
    TransportInfo ti = networkCapabilities.getTransportInfo();
    if (ti instanceof WifiAwareNetworkInfo) {
       WifiAwareNetworkInfo info = (WifiAwareNetworkInfo) ti;
       Inet6Address peerAddress = info.getPeerIpv6Addr();
       int peerPort = info.getPort();
    }
  }
  @Override
  public void onLost(Network network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback);

SYSTEM_ALERT_WINDOW sur les appareils Go

Les applications exécutées sur des appareils Android 10 (édition Go) ne peuvent pas recevoir les SYSTEM_ALERT_WINDOW l'autorisation. Cela est dû au fait que le dessin de fenêtres en superposition utilise trop de mémoire, ce qui est particulièrement préjudiciable aux performances des applications Android à faible mémoire appareils.

Si une application exécutée sur un appareil édition Go équipé d'Android 9 ou version antérieure reçoit l'événement SYSTEM_ALERT_WINDOW, l'application la conserve même si le est mis à niveau vers Android 10. Cependant, les applications qui ne l'ont pas encore L'autorisation ne peut pas être accordée après la mise à niveau de l'appareil.

Si une application sur un appareil Go envoie un intent avec l'action ACTION_MANAGE_OVERLAY_PERMISSION, le système refuse automatiquement la demande et redirige l'utilisateur Écran Settings (Paramètres) indiquant que l'autorisation n'est pas accordée, car elle ralentit l'appareil. Si une application sur un appareil Go appelle Settings.canDrawOverlays(), la méthode renvoie toujours "false". Encore une fois, ces restrictions ne s'appliquent pas aux applications qui a reçu l'autorisation SYSTEM_ALERT_WINDOW avant que l'appareil ne soit mis à niveau vers Android 10.

Avertissements pour les applications ciblant les anciennes versions d'Android

Les appareils équipés d'Android 10 ou version ultérieure avertissent les utilisateurs pour la première fois il exécute une application qui cible Android 5.1 (niveau d'API 22) ou version antérieure. Si l'application nécessite que l'utilisateur accorde des autorisations, il a également la possibilité d'ajuster les autorisations de l'application avant qu'elle ne soit autorisée à s'exécuter pour la première fois.

En raison de l'API cible de Google Play, exigences, Ces avertissements ne s'affichent que lorsqu'un utilisateur exécute une application qui n'a pas été mise à jour. récemment. Pour les applications distribuées via d'autres plates-formes, des exigences d'API cible similaires entreront en vigueur en 2019. Pour en savoir plus sur ces consultez la section Exigences liées au niveau d'API cible étendue dans 2019.

Suites de chiffrement CBC SHA-2 supprimées

Les suites de chiffrement SHA-2 CBC suivantes ont été supprimées de la plate-forme :

• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Ces suites de chiffrement sont moins sécurisées que les suites de chiffrement similaires qui utilisent GCM. La plupart des serveurs acceptent les variantes GCM et CBC de ces suites de chiffrement, ou n'en acceptent aucune.

Consommation par application

Android 10 introduit les changements de comportement suivants liés à l'utilisation des applications:

• Amélioration de l'utilisation des applications dans UsageStats : Android 10 suit précisément l'utilisation des applications avec UsageStats lorsque les applications en mode Écran partagé ou Picture-in-picture. En outre, Android 10 suit correctement l'utilisation des applis instantanées.

• Nuances de gris par application : Android 10 peut définir un mode d'affichage en nuances de gris pour chaque application.

• État de distraction par application : Android 10 peut définir de manière sélective les applications sur un "état de distraction" où ses notifications sont supprimées et n'apparaissent plus en tant qu'applications suggérées.

• Suspension et lecture : Sous Android 10, les applications suspendues ne peuvent pas lire de contenu audio.

Modifications des connexions HTTPS

Si une application exécutant Android 10 transmet null à setSSLSocketFactory(), une exception IllegalArgumentException se produit. Dans les versions précédentes, transmission de null à setSSLSocketFactory() a eu le même effet que de transmettre le par défaut usine.

La bibliothèque android.preference est obsolète

La bibliothèque android.preference est obsolète depuis Android 10. Les développeurs doivent plutôt utiliser la bibliothèque de préférences AndroidX, qui fait partie d'Android Jetpack. Pour obtenir des ressources supplémentaires pour faciliter la migration et le développement, consultez le guide des paramètres mis à jour, ainsi que notre application exemple publique et la documentation de référence.

Modifications apportées à la bibliothèque d'utilitaires de fichiers ZIP

Android 10 introduit les modifications suivantes apportées aux classes du package java.util.zip, qui gère les fichiers ZIP. Ces modifications améliorent le comportement de la bibliothèque cohérente entre Android et les autres plates-formes qui utilisent java.util.zip.

Gonfleur

Dans les versions précédentes, certaines méthodes de la classe Inflater généraient une IllegalStateException s'ils ont été appelés après un appel à end(). Dans Android 10, ces méthodes génèrent plutôt une exception NullPointerException.

Fichier ZIP

Dans Android 10 et versions ultérieures, le constructeur de ZipFile qui accepte des arguments de type File, int et Charset ne génère pas ZipException si le fichier ZIP fourni ne contient aucun fichier.

ZipOutputStream

Sur Android 10 ou version ultérieure, Méthode finish() dans ZipOutputStream ne génère pas de ZipException s'il tente d'écrire une le flux de sortie d’un fichier ZIP qui ne contient aucun fichier.

Modifications apportées à l'appareil photo

De nombreuses applications d'utilisation de l'appareil photo supposent que si l'appareil est en mode portrait, l'appareil physique est également en mode portrait, comme décrit dans Orientation de la caméra : C'était une hypothèse sûre par le passé, mais cela a changé avec l'élargissement des facteurs de forme disponibles, tels que les appareils pliables. Cela sur ces appareils peut entraîner une rotation ou une mise à l'échelle incorrecte (ou les deux) l'affichage du viseur de l'appareil photo.

Les applications qui ciblent le niveau d'API 24 ou supérieur doivent définir explicitement android:resizeableActivity et fournissent les fonctionnalités nécessaires pour gérer mode multifenêtre.

Suivi de l'utilisation de la batterie

À partir d'Android 10, SystemHealthManager réinitialise ses statistiques d'utilisation de la batterie chaque fois que l'appareil est débranché après un événement de recharge majeur. De manière générale, un événement de recharge majeur est: l'appareil a été complètement chargé, ou l'appareil est presque complètement déchargé. facturés.

Avant Android 10, les statistiques d'utilisation de la batterie étaient réinitialisées chaque fois que l'appareil était débranché, quelle que soit la faible variation du niveau de la batterie.

Abandon d'Android Beam

Dans Android 10, nous abandonnons officiellement Android Beam, une ancienne fonctionnalité pour en lançant le partage de données entre appareils via la technologie NFC (communication en champ proche). Nous abandonnons également plusieurs des API NFC associées. Android Beam reste disponibles en option pour les fabricants d’appareils partenaires qui souhaitent l’utiliser, mais il n’est pas plus longtemps en développement actif. Android continuera de prendre en charge d'autres et des API, ainsi que des cas d'utilisation tels que la lecture de balises les paiements continueront de fonctionner comme prévu.

Changement de comportement de java.math.BigDecimal.stripTrailingZeros()

BigDecimal.stripTrailingZeros() ne conserve plus les zéros finaux en tant que un cas particulier si la valeur d'entrée est zéro.

Modifications du comportement de java.util.regex.Matcher et du modèle

Le résultat de split() a été modifié pour ne plus commencer par un String vide ("") lorsqu'il existe une correspondance de largeur nulle au début de l'entrée. Cela affecte également String.split(). Par exemple, "x".split("") renvoie désormais {"x"} alors qu'il renvoyait auparavant {"", "x"} sur les anciennes versions d'Android. "aardvark".split("(?=a)" renvoie désormais {"a", "ardv", "ark"} au lieu de {"", "a", "ardv", "ark"}

Le comportement des exceptions pour les arguments non valides a également été amélioré:

• appendReplacement(StringBuffer, String) génère désormais une IllegalArgumentException au lieu de IndexOutOfBoundsException si le remplacement String se termine par une barre oblique inverse, ce qui n'est pas autorisé. La La même exception est désormais générée si l'String de remplacement se termine par $. Auparavant, aucune exception n'était générée dans ce scénario.
• replaceFirst(null) n'appelle plus reset() sur Matcher s'il génère une NullPointerException. Désormais, NullPointerException est également généré ne correspond pas. Auparavant, cette fonction n'était générée qu'en cas de correspondance.
• start(int group), end(int group) et group(int group) génèrent désormais une exception IndexOutOfBoundsException général si l'index du groupe est hors limites. Auparavant, ces méthodes généraient ArrayIndexOutOfBoundsException.

L'angle par défaut pour GradientDrawable est désormais TOP_BOTTOM

Dans Android 10, si vous définissez GradientDrawable en XML et ne fournissent pas de mesure d'angle, l'orientation du gradient la valeur par défaut est TOP_BOTTOM Il s'agit d'un changement par rapport aux versions précédentes d'Android, où la valeur par défaut était LEFT_RIGHT.

Pour contourner ce problème, si vous passez à la version la plus récente d'AAPT2, l'outil définit une mesure d'angle de 0 pour les anciennes applications en l'absence d'angle. est spécifiée.

Journalisation des objets sérialisés à l'aide du SUID par défaut

À partir d'Android 7.0 (niveau d'API 24), la plate-forme a apporté un correctif sur la valeur serialVersionUID par défaut pour les sérialisables objets. Ce correctif n'a pas eu d'incidence sur les applications ciblant le niveau d'API 23 ou inférieur.

À partir d'Android 10, si une application cible le niveau d'API 23 ou inférieur et s'appuie sur l'ancienne serialVersionUID par défaut incorrecte, le système enregistre un avertissement et suggère un correctif de code.

Plus précisément, le système consigne un avertissement si toutes les conditions suivantes sont remplies:

• L'application cible le niveau d'API 23 ou inférieur.
• Une classe est sérialisée.
• La classe sérialisée utilise la valeur serialVersionUID par défaut, au lieu de définir explicitement un serialVersionUID.
• La valeur serialVersionUID par défaut est différente de celle qui serait utilisée si l'application ciblait le niveau d'API 24 ou supérieur.

Cet avertissement est consigné une fois pour chaque classe concernée. Le message d'avertissement inclut une suggestion de correction, qui consiste à définir explicitement serialVersionUID à la valeur par défaut qui serait calculée si le niveau d'API 24 ou supérieur ciblé par l'application. En utilisant ce correctif, vous pouvez vous assurer que Si un objet de cette classe est sérialisé dans une application qui cible le niveau d'API 23 ou moins, l'objet sera lu correctement par les applications ciblant 24 ou plus, et vice versa.

Modifications apportées à java.io.FileChannel.map()

À partir d'Android 10, FileChannel.map() n'est plus compatible avec des fichiers non standards, comme /dev/zero, dont la taille ne peut pas être modifiée à l'aide de truncate() Précédent(e) d'Android a emporté l'erreur renvoyée par truncate(), mais Android 10 génère une exception IOException. Si vous avez besoin de l'ancien comportement, vous devez utiliser du code natif.