L'espace de stockage cloisonné limite l'accès des applications à l'espace de stockage externe. Dans Android 11 ou version ultérieure, les applications ciblant l'API 30 ou version ultérieure doivent utiliser un espace de stockage cloisonné. Auparavant, dans Android 10, les applications pouvaient désactiver l'espace de stockage cloisonné.
Restrictions d'accès aux applications
L'objectif de l'espace de stockage cloisonné est de protéger la confidentialité des données des applications et des utilisateurs. Cela inclut la protection des informations utilisateur (telles que les métadonnées des photos), l'empêchement des applications de modifier ou de supprimer des fichiers utilisateur sans autorisation explicite, et la protection des documents utilisateur sensibles téléchargés dans le dossier "Téléchargements" ou d'autres dossiers.
Les applications utilisant le stockage étendu peuvent avoir les niveaux d'accès suivants (l'accès réel dépend de l'implémentation).
- Accès en lecture et en écriture à leurs propres fichiers sans aucune autorisation
- Accès en lecture seule aux fichiers multimédias d'autres applications avec l'autorisation
READ_EXTERNAL_STORAGE - L'accès en écriture aux fichiers multimédias d'autres applications n'est autorisé qu'avec le consentement direct de l'utilisateur (des exceptions sont accordées à la galerie système et aux applications éligibles à l'accès à tous les fichiers).
- Aucun accès en lecture ni en écriture aux répertoires de données d'application externes d'autres applications
Utiliser le stockage cloisonné avec FUSE
Android 11 ou version ultérieure est compatible avec Filesystem in Userspace (FUSE), qui permet au module MediaProvider d'examiner les opérations sur les fichiers dans l'espace utilisateur et de contrôler l'accès aux fichiers en fonction de la règle allow, deny ou redact. Les applications utilisant FUSE dans un espace de stockage cloisonné bénéficient des fonctionnalités de confidentialité de l'espace de stockage cloisonné et de la possibilité d'accéder aux fichiers à l'aide d'un chemin d'accès direct aux fichiers (ce qui permet aux API File de continuer à fonctionner dans les applications).
Android 10 a appliqué des règles de stockage cloisonné aux accès aux fichiers par MediaProvider, mais pas pour l'accès direct au chemin d'accès aux fichiers (par exemple, à l'aide de l'API File et des API NDK) en raison de l'effort requis pour intercepter les appels du noyau. Par conséquent, les applications dans l'espace de stockage cloisonné ne pouvaient pas accéder aux fichiers à l'aide d'un chemin d'accès direct. Cette restriction a affecté la capacité des développeurs d'applications à s'adapter, car elle nécessitait des modifications importantes du code pour réécrire l'accès à l'API File vers l'API MediaProvider.
FUSE et SDCardFS
La prise en charge de FUSE par Android 11 n'est pas liée à l'abandon de SDCardFS, mais constitue une alternative à Media Store pour les appareils qui utilisaient auparavant SDCardFS. Appareils :
- Le lancement avec Android 11 ou version ultérieure à l'aide du noyau 5.4 ou version ultérieure ne permet pas d'utiliser SDCardFS.
- La mise à niveau vers Android 11 ou version ultérieure peut héberger FUSE au-dessus de SDCardFS pour intercepter les opérations sur les fichiers et atteindre les objectifs de confidentialité.
Réglage des performances de FUSE
Android était auparavant compatible avec FUSE dans Android 7 ou version antérieure, dans lequel le stockage externe était installé en tant que FUSE. En raison de problèmes de performances et de blocages avec cette implémentation FUSE, Android 8 a introduit SDCardFS. Android 11 réintroduit la prise en charge de FUSE à l'aide d'une implémentation améliorée et mieux testée de libfuse qui peut être ajustée pour résoudre les problèmes de performances dans Android 7 ou version antérieure.
Le réglage FUSE inclut les ajustements suivants :
- Contournement de FUSE pour les répertoires
Android/dataetAndroid/obbafin d'améliorer les performances des applications de jeux qui s'appuient sur ces répertoires. - Optimisations (comme l'ajustement des ratios de lecture anticipée et de données modifiées du système de fichiers FUSE) pour maintenir des lectures performantes et une lecture fluide des contenus multimédias.
- Utilisation du cache write-back FUSE.
- Mise en cache des autorisations pour réduire les IPC au serveur système.
- Optimisations pour les applications ayant accès à tous les fichiers afin d'accélérer les opérations groupées.
Les ajustements ci-dessus peuvent permettre d'obtenir des performances comparables entre les appareils FUSE et non FUSE. Par exemple, les tests effectués sur un Pixel 2 optimisé à l'aide de FUSE et sur un Pixel 2 à l'aide de Media Store ont révélé des performances de lecture séquentielle comparables (par exemple, la lecture de vidéos) entre l'accès au chemin d'accès aux fichiers et Media Store. Toutefois, les écritures séquentielles étaient légèrement moins performantes avec FUSE, et les lectures et écritures aléatoires pouvaient être jusqu'à deux fois plus lentes.
Les mesures de performances peuvent varier d'un appareil à l'autre et entre des cas d'utilisation spécifiques. Étant donné que les API MediaProvider offrent les performances les plus cohérentes, les développeurs d'applications soucieux des performances doivent les utiliser pour leurs applications.
Limiter l'impact sur les performances de FUSE
L'impact sur les performances de FUSE se limite aux utilisateurs intensifs de fichiers stockés sur un espace de stockage partagé externe. Le stockage privé externe (qui inclut les répertoires android/data et android/obb) est contourné par FUSE, tandis que le stockage interne (tel que /data/data, où de nombreuses applications stockent des données pour les garder chiffrées et sécurisées) n'est pas monté par FUSE.
Les applications qui utilisent peu le stockage externe partagé interagissent souvent avec un ensemble limité de fichiers (généralement moins de 100 fichiers). Ces applications bénéficient des optimisations existantes des opérations de lecture et d'écriture courantes, et ne devraient pas subir d'impact sur les performances lié à FUSE dans Android 11.
Les applications qui utilisent beaucoup de mémoire de stockage externe partagée effectuent généralement des opérations sur des fichiers en masse, comme lister ou supprimer un répertoire contenant 1 000 fichiers, ou créer ou supprimer un répertoire contenant un million de fichiers sur le système de fichiers. Les opérations sur les fichiers groupés peuvent être affectées par FUSE sur Android 11, mais si ces applications sont éligibles à l'autorisation
MANAGE_EXTERNAL_STORAGE, elles bénéficient des optimisations de performances incluses dans la mise à jour d'octobre 2020.
Pour éviter les frais généraux liés aux performances de FUSE, les applications peuvent stocker des données dans un espace de stockage externe privé ou utiliser des API groupées dans la classe ContentProvider pour contourner FUSE et obtenir un chemin optimisé pour les performances. De plus, la mise à jour d'octobre 2020 du composant système MediaProvider inclut des optimisations de performances pour les gestionnaires de fichiers et les applications similaires (telles que la sauvegarde/restauration et l'antivirus) qui détiennent l'autorisation MANAGE_EXTERNAL_STORAGE.
La confidentialité avant les performances
Sur les appareils optimisés pour FUSE, la plupart des parcours utilisateur critiques sont aussi performants sous Android 10 que sous Android 11. Toutefois, lors des tests de référence sur un ensemble d'opérations sur les fichiers, Android 11 peut être moins performant qu'Android 10. Pour les modèles d'accès aux fichiers qui fonctionnent moins bien sous Android 11 (par exemple, les lectures ou écritures aléatoires), nous vous recommandons d'utiliser les API MediaProvider pour donner aux applications un mode d'accès non FUSE, qui est la meilleure option et offre des performances constantes.
Mises à jour de MediaProvider et FUSE
Le comportement du composant système MediaProvider diffère selon les versions d'Android.
Dans Android 10 et les versions antérieures, SDCardFS était le système de fichiers et MediaProvider fournissait une interface pour les collections de fichiers (par exemple, les images, les vidéos, les fichiers musicaux, etc.). Lorsqu'une application créait un fichier à l'aide de l'API File, elle pouvait demander à MediaProvider d'analyser le fichier et de l'enregistrer dans la base de données.
Dans Android 11 ou version ultérieure, SDCardFS est obsolète et MediaProvider devient le gestionnaire du système de fichiers (pour FUSE) pour le stockage externe, ce qui rend le système de fichiers sur le stockage externe et la base de données MediaProvider cohérents. En tant que gestionnaire d'espace utilisateur pour le système de fichiers FUSE, MediaProvider peut intercepter les appels du noyau et s'assurer que les opérations sur les fichiers respectent la confidentialité.
Dans Android 11 et versions ultérieures, MediaProvider est également un composant système modulaire (un module Mainline) qui peut être mis à jour en dehors des versions d'Android. Cela signifie que les problèmes de performances, de confidentialité ou de sécurité détectés dans MediaProvider peuvent être corrigés et distribués par voie hertzienne depuis le Google Play Store ou d'autres mécanismes fournis par des partenaires. Tout ce qui relève du champ d'application d'un gestionnaire FUSE est également modifiable, ce qui permet de corriger les régressions et les bugs liés aux performances de FUSE.