Changements de comportement : toutes les applications

Android 10 apporte des modifications de comportement susceptibles d'affecter votre application. Les modifications listées sur cette page s'appliquent à votre application lorsqu'elle s'exécute sur Android 10, quelle que soit la targetSdkVersion de l'application. Vous devez tester votre application et la modifier si nécessaire afin de prendre en charge ces modifications.

Si la valeur targetSdkVersion de votre application est 29 ou supérieure, vous devrez également prendre en charge d'autres modifications. Pour en savoir plus, consultez Changements de comportement pour les applications ciblant la version 29.

Restrictions des interfaces hors SDK

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

Si vous ne ciblez pas Android 10 (niveau d'API 29), certaines de ces modifications ne vous affecteront peut-être pas immédiatement. Cependant, bien que vous puissiez actuellement utiliser certaines 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é d'endommager votre 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 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'alternative à l'utilisation d'une interface non SDK pour une fonctionnalité de votre application, vous devriez demander une nouvelle API publique.

Pour en savoir plus, consultez Mises à jour des restrictions d'interface non SDK dans Android 10 et 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 de l'appareil, qu'elles ciblent ou non le niveau d'API 29. Par exemple, si l'utilisateur balaie l'écran depuis le bord, le système interprète ce geste comme un retour en arrière, sauf si une application remplace spécifiquement ce geste pour certaines parties de l'écran.

Pour rendre votre application compatible avec la navigation par gestes, vous devez étendre le contenu de l'application d'un bord à l'autre et gérer les gestes conflictuels de manière appropriée. Pour en savoir plus, consultez la documentation sur la navigation par gestes.

NDK

Android 10 inclut les modifications suivantes du NDK.

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

Android 6.0 (niveau d'API 23) interdit l'utilisation de réadressages de code dans les objets partagés. Le code doit être chargé tel quel et ne doit pas être modifié. Ce changement améliore les temps de chargement et la sécurité des applications.

SELinux applique cette restriction aux applications qui ciblent Android 10 ou version ultérieure. Si ces applications continuent d'utiliser des objets partagés contenant des relocalisations de texte, elles risquent fortement de ne plus fonctionner.

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

À partir d'Android 10, plusieurs chemins d'accès sont des liens symboliques au lieu de fichiers standards. Les applications qui s'appuient sur des chemins d'accès à des fichiers standards peuvent 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, lib/ étant remplacé par lib64/.

Pour assurer la compatibilité, les liens symboliques sont fournis aux anciens chemins d'accès. Par exemple, /system/lib/libc.so est un lien symbolique vers /apex/com.android.runtime/lib/bionic/libc.so. dlopen(“/system/lib/libc.so”) continue donc de fonctionner, mais les applications détecteront la différence lorsqu'elles tenteront d'examiner les bibliothèques chargées en lisant /proc/self/maps ou un élément similaire. Ce n'est pas habituel, mais nous avons constaté que certaines applications le font dans le cadre de leur processus de lutte contre le piratage. Si tel est le cas, les chemins d'accès /apex/… doivent être ajoutés en tant que chemins d'accès valides pour les fichiers Bionic.

Bibliothèques/binaires système mappés à la mémoire en exécution seule

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

Vous pouvez déterminer si ce comportement a provoqué un plantage en examinant le fichier tombstone associé dans /data/tombstones/. Un plantage lié à l'exécution seule 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'outil d'inspection de la mémoire, il est possible de marquer les segments en exécution seule comme étant en lecture et exécution en appelant mprotect(). Toutefois, nous vous recommandons vivement de rétablir l'autorisation d'exécution seule par la suite, car ce paramètre d'autorisation d'accès offre une meilleure protection pour votre application et vos utilisateurs.

Sécurité

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

TLS 1.3 activé par défaut

Sur Android 10 ou version ultérieure, TLS 1.3 est activé par défaut pour toutes les connexions TLS. Voici quelques détails importants sur notre mise en œuvre de TLS 1.3 :

• Les suites de chiffrement TLS 1.3 ne peuvent pas être personnalisées. Les suites de chiffrement TLS 1.3 prises en charge sont toujours activées lorsque que TLS 1.3 est activé. Toute tentative de désactivation en appelant setEnabledCipherSuites() est ignorée.
• Lorsque TLS 1.3 est négocié, les objets HandshakeCompletedListener sont appelés avant que les sessions ne soient ajoutées au cache de session. (Dans TLS 1.2 et d'autres versions antérieures, ces objets sont appelés après l'ajout des sessions au 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 élément 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 appelant setEnabledProtocols() sur un objet approprié.

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

Dans 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é de certificats de ce type depuis 2016 et 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 qui présente un certificat 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 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. Il convient de noter que cette invite ne contient pas d'options non conformes aux spécifications du serveur.

Si aucun certificat sélectionnable par l'utilisateur n'est disponible (par exemple, si aucun certificat ne correspond aux spécifications du serveur ou si un appareil ne dispose d'aucun certificat installé), 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 verrouiller 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 dans Android 10 :

• Les algorithmes de chiffrement AES/GCM/NoPadding et ChaCha20/Poly1305/NoPadding renvoient des tailles de mémoire tampon plus précises à partir de getOutputSize().
• La suite de chiffrement TLS_FALLBACK_SCSV est omise pour les tentatives de connexion avec un protocole maximal TLS 1.2 ou supérieur. En raison des améliorations apportées aux implémentations des serveurs TLS, nous vous déconseillons de tenter un remplacement externe TLS. Nous vous recommandons plutôt 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ée 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 des signatures RSA-PSS dans TLS.

Diffusions Wi-Fi Direct

Sur Android 10, les diffusions 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 s'appuyait sur la réception de ces diffusions lors de l'enregistrement, car elles étaient persistantes, utilisez la méthode get() appropriée lors de l'initialisation pour obtenir les informations.

Fonctionnalités Wi-Fi Aware

Android 10 ajoute la compatibilité pour faciliter la création de sockets TCP/UDP à l'aide de chemins de données Wi-Fi Aware. Pour créer un socket TCP/UDP se connectant à un ServerSocket, l'appareil client doit connaître l'adresse IPv6 et le port du serveur. Auparavant, ces informations devaient être communiquées hors bande, par exemple à l'aide de la messagerie de couche 2 BT ou Wi-Fi Aware, ou découvertes dans la bande à l'aide d'autres protocoles, tels que 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, puis définissez ou obtenez le port à utiliser.
• Spécifiez les informations de port dans la requête réseau Wi-Fi Aware.

L'exemple de code suivant montre comment spécifier les informations de port dans la 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 effectue ensuite une requête réseau Wi-Fi Aware pour obtenir l'IPv6 et le port fournis 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 l'autorisation SYSTEM_ALERT_WINDOW. En effet, le dessin de fenêtres de superposition utilise une quantité excessive de mémoire, ce qui nuit particulièrement aux performances des appareils Android à faible capacité de mémoire.

Si une application exécutée sur un appareil Go Edition équipé d'Android 9 ou version antérieure reçoit l'autorisation SYSTEM_ALERT_WINDOW, elle la conserve même si l'appareil est mis à niveau vers Android 10. Toutefois, les applications qui ne disposent pas déjà de cette autorisation ne peuvent pas l'obtenir 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 requête et redirige l'utilisateur vers un écran Paramètres qui indique 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". Là encore, ces restrictions ne s'appliquent pas aux applications ayant reçu l'autorisation SYSTEM_ALERT_WINDOW avant la mise à niveau de l'appareil vers Android 10.

Avertissements pour les applications ciblant d'anciennes versions d'Android

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

En raison des exigences d'API cible de Google Play, un utilisateur ne voit ces avertissements que lorsqu'il 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 similaires concernant le niveau d'API cible entreront en vigueur en 2019. Pour en savoir plus sur ces exigences, consultez Expanding target API level requirements in 2019 (Élargissement des exigences liées au niveau d'API cible en 2019).

Suites de chiffrement SHA-2 CBC 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, et la plupart des serveurs sont compatibles avec les variantes GCM et CBC de ces suites de chiffrement, ou ne sont compatibles avec aucune d'entre elles.

Consommation par application

Android 10 introduit les changements de comportement suivants concernant l'utilisation des applications :

• Améliorations de l'utilisation des applications UsageStats : Android 10 suit précisément l'utilisation des applications avec UsageStats lorsque les applications sont utilisées en mode Écran partagé ou Picture-in-picture. De plus, Android 10 suit correctement l'utilisation des applications instantanées.

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

• État de distraction par application : Android 10 peut définir de manière sélective les applications sur un "état de distraction" dans lequel leurs notifications sont supprimées et n'apparaissent pas comme des 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, transmettre null à setSSLSocketFactory() avait le même effet que transmettre la fabrique par défaut actuelle.

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 facilitant la migration et le développement, consultez le guide des paramètres mis à jour, ainsi que notre exemple d'application public et notre documentation de référence.

Modifications de la bibliothèque d'utilitaires de fichiers ZIP

Android 10 introduit les modifications suivantes dans les classes du package java.util.zip, qui gère les fichiers ZIP. Ces modifications rendent le comportement de la bibliothèque plus cohérent entre Android et les autres plates-formes qui utilisent java.util.zip.

Inflater

Dans les versions précédentes, certaines méthodes de la classe Inflater généraient une exception IllegalStateException si elles étaient appelées après un appel à end(). Dans Android 10, ces méthodes génèrent une exception NullPointerException.

ZipFile

Sous Android 10 ou version ultérieure, le constructeur de ZipFile qui accepte les arguments de type File, int et Charset ne génère pas d'ZipException si le fichier ZIP fourni ne contient aucun fichier.

ZipOutputStream

Sous Android 10 ou version ultérieure, la méthode finish() dans ZipOutputStream ne génère pas d'ZipException si elle tente d'écrire un flux de sortie pour un fichier ZIP qui ne contient aucun fichier.

Changements de caméra

De nombreuses applications utilisant 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 l'appareil photo. C'était une hypothèse sûre par le passé, mais cela a changé avec l'expansion des facteurs de forme disponibles, tels que les pliables. Cette hypothèse sur ces appareils peut entraîner une rotation ou une mise à l'échelle incorrecte (ou les deux) de 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 fournir les fonctionnalités nécessaires pour gérer le fonctionnement 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. En règle générale, un événement de recharge majeur correspond à l'un des cas suivants : l'appareil a été complètement rechargé, ou l'appareil est passé d'un état de décharge quasi totale à un état de recharge quasi complète.

Avant Android 10, les statistiques d'utilisation de la batterie étaient réinitialisées chaque fois que l'appareil était débranché, même si le niveau de batterie n'avait que peu changé.

Abandon d'Android Beam

Dans Android 10, nous abandonnons officiellement Android Beam, une ancienne fonctionnalité permettant de lancer le partage de données entre appareils via la technologie NFC (Near Field Communication). Nous abandonnons également plusieurs API NFC associées. Android Beam reste disponible en option pour les fabricants d'appareils partenaires qui souhaitent l'utiliser, mais il n'est plus en développement actif. Android continuera toutefois de prendre en charge d'autres fonctionnalités et API NFC, et les cas d'utilisation tels que la lecture de tags et les paiements continueront de fonctionner comme prévu.

Modification du comportement de java.math.BigDecimal.stripTrailingZeros()

BigDecimal.stripTrailingZeros() ne conserve plus les zéros de fin comme cas particulier si la valeur d'entrée est zéro.

Modifications du comportement de java.util.regex.Matcher et Pattern

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 {"", "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 d'une IndexOutOfBoundsException si le remplacement String se termine par une barre oblique inverse seule, ce qui n'est pas autorisé. La même exception est désormais générée si le remplacement String se termine par un $. 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. NullPointerException est désormais également généré lorsqu'il n'y a pas de correspondance. Auparavant, elle n'était générée que lorsqu'une correspondance était trouvée.
• start(int group), end(int group) et group(int group) génèrent désormais une exception IndexOutOfBoundsException plus générale si l'index du groupe est hors limites. Auparavant, ces méthodes généraient ArrayIndexOutOfBoundsException.

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

Sous Android 10, si vous définissez un GradientDrawable en XML et que vous ne fournissez pas de mesure d'angle, l'orientation du dégradé est définie par défaut sur 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 si aucune mesure d'angle n'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 corrigé le serialVersionUID par défaut pour les objets sérialisables. Ce correctif n'a pas affecté 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'ancien serialVersionUID par défaut incorrect, le système consigne un avertissement et suggère une correction du 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 le serialVersionUID par défaut, au lieu de définir explicitement un serialVersionUID.
• La valeur par défaut de serialVersionUID est différente de celle de serialVersionUID 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 sur la valeur par défaut qui serait calculée si l'application ciblait le niveau d'API 24 ou supérieur. En utilisant ce correctif, vous pouvez vous assurer que si un objet de cette classe est sérialisé sur une application qui cible le niveau d'API 23 ou une version antérieure, l'objet sera correctement lu par les applications qui ciblent le niveau 24 ou une version ultérieure, et inversement.

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

À partir d'Android 10, FileChannel.map() n'est pas compatible avec les fichiers non standards, comme /dev/zero, dont la taille ne peut pas être modifiée à l'aide de truncate(). Les versions précédentes d'Android ont absorbé l'errno renvoyé 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.