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".
Remarque : Outre les modifications mentionnées sur cette page, Android 10 introduit un grand nombre de modifications et de restrictions liées à la confidentialité, y compris les éléments suivants:
- Accès en arrière-plan à la position de l'appareil
- Démarrage de l'activité en arrière-plan
- Informations sur l'affinité des contacts
- Randomisation de l'adresse MAC
- Métadonnées de l'appareil photo
- Modèle d'autorisations
Ces modifications affectent toutes les applications et renforcent la confidentialité des utilisateurs. Pour en savoir plus sur la prise en charge de ces changements, consultez la Modifications concernant la confidentialité.
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 exceptionSSLHandshakeException
sur des versions antérieures d'Android, elles génèrent une exceptionSSLProtocolException
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:
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:
Kotlin
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()
Java
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:
Kotlin
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)
Java
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 uneIllegalArgumentException
au lieu deIndexOutOfBoundsException
si le remplacementString
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 plusreset()
surMatcher
s'il génère uneNullPointerException
. 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)
etgroup(int group)
génèrent désormais une exceptionIndexOutOfBoundsException
général si l'index du groupe est hors limites. Auparavant, ces méthodes généraientArrayIndexOutOfBoundsException
.
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 unserialVersionUID
. - 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.