Qu'est-ce que /storage/emulated/0/?

/storage/emulated/0/ est en fait /data/media/0/ exposés à travers un système de fichiers émulé / virtuel, et non le système réel.

Ceci en référence à ma réponse précédente ici mais avec des détails plus pertinents.

Android STORAGE :

Sur Android 5 :

/sdcard >S> /storage/emulated/legacy >S> /mnt/shell/emulated/0
/mnt/shell/emulated >E> /data/media

Sur Androïd 6+. :

# for (Java) Android apps (running inside zygote virtual machine)
# "/storage to VIEW" bind mount is inside a separate mount namespace for every app
/sdcard >S> /storage/self/primary
/storage/self >B> /mnt/user/USER-ID
/mnt/user/USER-ID/primary >S> /storage/emulated/USER-ID
/storage/emulated >B> /mnt/runtime/VIEW/emulated
/mnt/runtime/VIEW/emulated >E> /data/media

# for services/daemons/processes in root/global namespace (VIEW = default)
/sdcard >S> /storage/self/primary
/storage >B> /mnt/runtime/default
/mnt/runtime/default/self/primary >S> /mnt/user/USER-ID/primary
/mnt/user/USER-ID/primary >S> /storage/emulated/USER-ID
/storage/emulated >B> /mnt/runtime/default/emulated
/mnt/runtime/default/emulated >E> /data/media

* >S> pour le lien symbolique, >E> pour l'émulation et >B> pour le montage de bind
* USER-ID de l'utilisateur actuel en cas de Multiple Users o Work Profile normalement 0 c'est-à-dire celui du propriétaire du dispositif
* VIEW est l'un des read (pour les applications avec permission.READ_EXTERNAL_STORAGE) ou write (permission.WRITE_EXTERNAL_STORAGE) ou default (pour les processus fonctionnant dans l'espace de noms Root/global mount, c'est-à-dire en dehors de zygote)
* Il y avait des différences mineures sur les versions précédentes d'Android, mais le concept d'émulation est resté le même depuis sa mise en œuvre.
* Pour un peu plus de détails sur l'implémentation de l'espace de noms mount d'Android, voir ceci réponse .

En bref, /sdcard y /storage/emulated/0 - qui représentent un système de fichiers FAT/vFAT/FAT32 - pointent vers /data/media/0 (ou /mnt/expand/[UUID]/media/0 en cas de Stockage adoptif ) par FUSE o sdcardfs l'émulation.

N'étant pas spécifique à Android mais généralement lié à Linux, lien symbolique y Fixer le support (voir "Création d'un support de liaison") sont hors de portée de cette question, puisque la question porte principalement sur la partie émulation.

EMULATION :

Pourquoi l'émulation est là ? Le système de fichiers émulé est une couche d'abstraction sur le système de fichiers réel ( ext4 o f2fs ) qui sert essentiellement deux objectifs :

• Conserver la connectivité USB des appareils Android avec les PC (mise en œuvre par MTP de nos jours).
• Limitez l'accès non autorisé des applications/processus aux médias privés de l'utilisateur et aux données des autres applications sur la carte SD.

Lire Le parcours de stockage d'Android pour les détails, le résumé est :

Les premiers appareils Android ne disposaient que d'une faible capacité de stockage interne et s'appuyaient sur des cartes SD (physiquement) externes qui utilisent traditionnellement la famille de systèmes de fichiers FAT pour garantir la compatibilité avec la plupart des PC (voir la domination de Microsoft sur le monde des PC).
Lorsque la taille du stockage interne a augmenté, le même système de fichiers a été transféré sur la carte SD interne (encore appelée "externe").
Mais la mise en œuvre de FAT/vFAT présentait deux problèmes majeurs qui ont été résolus progressivement par Google :

• Les appareils Android étaient connectés directement aux PC ( Mémoire de masse USB ) tout comme nous connectons une clé USB de nos jours. UMS expose le dispositif au niveau du bloc et déconnecte la carte SD du cadre Android (démonte), rendant ainsi toutes les données indisponibles pour les applications et brisant éventuellement de nombreuses fonctionnalités.
• La FAT (étant la préférée de Windows à l'époque du développement) n'a jamais été conçue pour appliquer les permissions UNIX (mode, uid, gid et autres). liens symétriques y ioctls comme FS_IOC_FIEMAP ). Ainsi, toutes les données de la carte SD étaient accessibles à toutes les applications (puisque chaque application Android est un utilisateur UNIX/Linux et possède un uid) sans aucune restriction, ce qui soulève de graves problèmes de confidentialité et de sécurité.

Ces deux problèmes ont été résolus par l'émulation :

• Le stockage réel sur carte SD a été déplacé vers /data (ou la partition indépendante /sdcard sur certains appareils auparavant) qui contient les données suivantes ext4 (progressivement remplacé par le système de fichiers f2fs ), mettant pleinement en œuvre les permissions UNIX.
• Cette conception rendait l'utilisation de l'UMS impossible parce que des /data La partition ne pouvait pas être exposée au PC pour deux autres raisons : (1) il contient un grand nombre de paramètres et de données d'applications qui doivent être protégés contre les autres applications et les utilisateurs humains. (2) Les systèmes de fichiers Linux ne sont pas pris en charge par Windows.
  L'UMS a donc été remplacé par le Media Transfer Protocol, qui est une extension de type client-serveur du PTP - un protocole déjà établi. MTP n'expose pas le dispositif de blocage mais fonctionne par le biais de la pile logicielle. L'hôte MTP fonctionne sur Android comme une application ( android.process.media ) entièrement sandboxé dans le cadre d'Android, incapable d'effectuer des tâches de haut niveau.

Maintenant, les applications (et MTP, qui est aussi une application) interagissent avec le stockage émulé au lieu de /data/media Il s'agit d'un système qui atteint les deux objectifs en même temps, c'est-à-dire qu'il applique des contrôles de permission en dessous et ressemble à un système de fichiers FAT sur la surface supérieure.

Google met maintenant en œuvre l'émulation par sdcardfs pour pallier les insuffisances de FUSE l'une des principales étant la surcharge d'entrée/sortie, c'est-à-dire l'amélioration des vitesses de lecture/écriture.

LES AUTORISATIONS DE STOCKAGE EXTERNE :
Concept de Fichiers publics et privés sur le stockage externe peut être démontré à l'aide d'un exemple :
Installez l'application Termux.
Créer des répertoires /sdcard/Android/data/com.termux/test_dir y /sdcard/test_dir .
Créer des fichiers /sdcard/Android/data/com.termux/test_file y /sdcard/test_file .
Exécutez les commandes suivantes :

* Vous devez avoir installé WhatsApp ou sélectionner le dossier privé d'une autre application.

Maintenant, forcez l'arrêt de l'application Termux et accordez Autorisation de stockage . Exécutez à nouveau les commandes :

Voyez la différence entre les permissions des mêmes fichiers et répertoires. Cela ne semble pas être possible sans émulation sur un système de fichiers Linux natif lorsqu'il y a des centaines d'applications (utilisateurs) à traiter simultanément. C'est l'émulation du système de fichiers qui permet au même fichier d'être exposé avec trois ensembles différents de permissions en même temps, indépendamment de ses permissions originales sur le système de fichiers réel :

# touch /data/media/0/test_file

# stat -c '%a %u %g %n' /data/media/0/test_file
644 1023 1023 /data/media/0/test_file

# stat -c '%a %u %g %n' /mnt/runtime/*/emulated/0/test_file
660 0 1015 /mnt/runtime/default/emulated/0/test_file
640 0 9997 /mnt/runtime/read/emulated/0/test_file
660 0 9997 /mnt/runtime/write/emulated/0/test_file

Voir aussi Qu'est-ce que l'UID "u#_everybody" ?

En rapport :

• Pourquoi le répertoire 'storage/emulated/' est-il inaccessible ?
• Comment puis-je faire un lien symbolique (ou équivalent) à l'intérieur de /storage/emulated/0 ?