Qu'est-ce que / stockage / émulé / 0 /?

Récemment, je l' ai compris que si je supprime des fichiers depuis /sdcard/Downloadqu'il supprime les fichiers de /storage/emulated/0/Download. Et si j'y ajoute les fichiers, /sdcard/Downloadil les duplique /storage/emulated/0/Download.

Alors c'est quoi /storage/emulated/0/? À quelles fins l’avons-nous dans notre système de fichiers Android?

/storage/emulated/0/Download est le chemin d'accès réel aux fichiers.

/sdcard/Download est un lien symbolique vers le chemin réel de /storage/emulated/0/Download

Cependant, les fichiers réels sont situés dans le système de fichiers dans /data/media, qui est ensuite monté sur /storage/emulated/0(et souvent aussi d'autres points de montage)

A Symlink Dans le calcul, un lien symbolique est un terme pour un fichier qui contient une référence à un autre fichier ou un répertoire sous la forme d'un chemin absolu ou relatif et qui affecte la résolution des chemins. Les liens symboliques étaient déjà présents en 1978 dans les systèmes d'exploitation pour mini-ordinateurs de RDOS et RDOS de Data General.

/storage/emulated/0/est réellement /data/media/0/exposé par le biais d’un système de fichiers virtuel / émulé, et non du système actuel.

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

STOCKAGE ANDROID:

Sur Android 5 :

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

Sur Android 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

<sup>* >S>pour le lien symbolique, >E>pour l'émulation et >B>pour le montage lié
* USER-IDde l'utilisateur actuel en cas de Multiple Usersou Work Profile, normalement 0, le propriétaire de l'appareil
* VIEWest l'une des readapplications (pour les applications avec permission.READ_EXTERNAL_STORAGE) ou write(permission.WRITE_EXTERNAL_STORAGE) ou default(pour les processus exécutés à la racine / global mount namespace, c'est-à-dire en dehors de zygote)
* Il existait des différences mineures entre les versions précédentes d'Android, mais le concept d'émulation était le même depuis sa mise en œuvre.
* Pour un peu plus de détails sur l'implémentation de l'espace de noms de montage d'Android, voir cette réponse. .</sup>

En bref, /sdcardet /storage/emulated/0qui - qui représentent un système de fichiers FAT / vFAT / FAT32 - pointent vers /data/media/0(ou /mnt/expand/[UUID]/media/0dans le cas de Adoptable Storage ) via FUSEousdcardfs émulation.

N'étant pas spécifique à Android, mais généralement lié à Linux, lien de montage et liaison (voir "Création d'un montage ") sortent du cadre de cette question, car la question porte principalement sur l'émulation.

ÉMULATION:

Pourquoi l'émulation est ici? Le système de fichiers émulé est une couche d'abstraction sur un système de fichiers réel ( ext4ou f2fs) ayant deux objectifs principaux:

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

Lisez le voyage de stockage d'Android pour plus de détails, le résumé est:

Les premiers appareils Android manquaient de stockage interne et utilisaient (physiquement) des cartes SD externes qui utilisent traditionnellement la famille de systèmes de fichiers FAT pour assurer la compatibilité avec la plupart des PC (reportez-vous à la domination de Microsoft sur le monde des PC).
Lorsque la taille de la mémoire de stockage interne a augmenté, le même système de fichiers a été déplacé sur une carte SD interne (encore appelée "externe").
Mais la mise en œuvre de FAT / vFAT présentait deux problèmes majeurs qui ont été abordés par Google progressivement:

• Les appareils Android étaient directement connectés aux PC ( stockage de masse USB ), tout comme nous connectons un lecteur USB de nos jours. UMS expose le périphérique au niveau des blocs et déconnecte la carte SD du framework Android (démonte), rendant ainsi l'intégralité des données inaccessibles aux applications et éventuellement supprimant de nombreuses fonctionnalités.
• FAT (étant le favori de Windows dans les jours de développement) n'a jamais été conçu pour appliquer des autorisations UNIX (mode, uid, gid et même des liens symboliques , ioctlsetc. FS_IOC_FIEMAP). Ainsi, toutes les données sur la carte SD étaient disponibles pour toutes les applications (étant donné que chaque application Android est un utilisateur UNIX / Linux et possède un ID utilisateur) sans restrictions, ce qui pose de graves problèmes de confidentialité et de sécurité.

Les deux problèmes ont été résolus par émulation:

• Le stockage réel sur carte SD a été déplacé vers une /datapartition (ou une partition indépendante / sdcard sur certains périphériques précédemment) qui contient le ext4système de fichiers (progressivement remplacé par f2fs), mettant pleinement en œuvre les autorisations UNIX.
• Cette conception rendait impossible l'utilisation d'UMS car toute la /datapartition ne pouvait pas être exposée au PC pour deux autres raisons: (1)elle contient beaucoup de paramètres et de données d'applications qui doivent être protégés des autres applications ainsi que des utilisateurs. (2)Les systèmes de fichiers Linux ne sont pas pris en charge par Windows.
  Ainsi, UMS a été remplacé par Media Transfer Protocol, qui est une extension de type client-serveur pour PTP - un protocole déjà établi. MTP n'expose pas les périphériques en mode bloc mais fonctionne via une pile logicielle. L'hôte MTP s'exécute sur Android en tant qu'application ( android.process.media) entièrement en mode bac à sable dans le cadre Android, incapable d'effectuer des tâches en escalade.

Désormais, les applications (et MTP, qui est également une application) interagissent avec le stockage émulé au lieu de /data/media, réalisant les deux objectifs en même temps, c’est-à-dire appliquer des contrôles d’autorisation en dessous et ressembler au système de fichiers FAT sur la surface supérieure.

Google implémente maintenant l'émulation via sdcardfs pour surmonter les défauts de FUSE ; l'un des principaux étant la surcharge d'entrée / sortie, c'est-à-dire d'améliorer les vitesses de lecture / écriture.

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

^{* Vous devriez avoir WhatsApp installé ou sélectionner le dossier privé d'une autre application.}

Forcez maintenant l'arrêt de l'application Termux et accordez l' autorisation de stockage . Exécutez à nouveau les commandes:

Voyez la différence dans les autorisations des mêmes fichiers et répertoires. Cela semble ne pas être possible simplement sans émulation sur un système de fichiers Linux natif lorsqu'il existe des centaines d'applications (utilisateurs) à gérer simultanément. C'est l'émulation du système de fichiers qui permet d'exposer le même fichier avec trois jeux d'autorisations différents en même temps, indépendamment de ses autorisations d'origine 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 relation:

• Pourquoi le répertoire 'stockage / émulé /' est-il inaccessible?
• Comment créer un lien symbolique (ou équivalent) dans / storage / emulated / 0?