Kürzlich habe ich herausgefunden, dass beim Löschen von Dateien /sdcard/DownloadDateien von gelöscht werden /storage/emulated/0/Download. Und wenn ich die Dateien hinzufüge, werden /sdcard/Downloadsie darin dupliziert /storage/emulated/0/Download.
Also was ist /storage/emulated/0/? Für welche Zwecke haben wir es in unserem Android-Dateisystem?
Antworten:
/storage/emulated/0/Download ist der tatsächliche Pfad zu den Dateien.
/sdcard/Download ist ein Symlink zum aktuellen Pfad von /storage/emulated/0/Download
Die eigentlichen Dateien befinden sich jedoch im Dateisystem, in /data/mediadas dann /storage/emulated/0(und häufig auch andere Mountpunkte) eingehängt werden.
Ein Symlink In der Datenverarbeitung ist ein symbolischer Link ein Begriff für jede Datei, die einen Verweis auf eine andere Datei oder ein anderes Verzeichnis in Form eines absoluten oder relativen Pfads enthält und die Auflösung von Pfadnamen beeinflusst. Symbolische Verknüpfungen waren bereits 1978 in Minicomputer-Betriebssystemen von DEC und Data Generals RDOS vorhanden.
/storage/emulated/0/wird tatsächlich /data/media/0/durch ein emuliertes / virtuelles Dateisystem verfügbar gemacht, nicht durch das tatsächliche.
Dies ist mit Bezug auf meine vorherige Antwort hier , aber mit relevanteren Details.
Auf Android 5 :
/sdcard >S> /storage/emulated/legacy >S> /mnt/shell/emulated/0
/mnt/shell/emulated >E> /data/media
Auf 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
* >S>für symlink, >E>für emuliertes und >B>für bind mount
* USER-IDdes aktuellen Benutzers im Falle von Multiple Usersoder Work Profile, normalerweise 0dh des Gerätebesitzers
* VIEWist eine von read(für Apps mit permission.READ_EXTERNAL_STORAGE) oder write(permission.WRITE_EXTERNAL_STORAGE) oder default(für Prozesse, die im Root ausgeführt werden / globaler Mount-Namespace (dh außerhalb von Zygote)
* Bei früheren Android-Versionen gab es geringfügige Unterschiede, aber das Konzept der Emulation war seitdem dasselbe.
* Weitere Informationen zur Implementierung des Mount-Namespace für Android finden Sie in dieser Antwort .
Kurz gesagt, /sdcardund /storage/emulated/0- die ein FAT / vFAT / FAT32-Dateisystem darstellen - auf /data/media/0(oder /mnt/expand/[UUID]/media/0im Fall von Adoptable Storage ) durch FUSEoder sdcardfsEmulation verweisen .
Symlink und Bind-Mount (siehe "Bind-Mount erstellen") sind nicht für Android, sondern generell für Linux bestimmt und fallen nicht in den Geltungsbereich dieser Frage, da es sich hauptsächlich um einen Emulationsteil handelt.
Warum ist die Emulation hier? Das emulierte Dateisystem ist eine Abstraktionsschicht auf dem tatsächlichen Dateisystem ( ext4oder f2fs), die im Wesentlichen zwei Zwecken dient:
Weitere Informationen finden Sie in der Android Storage Journey . Die Zusammenfassung lautet:
Frühe Android-Geräte verfügten nicht über ausreichend internen Speicher und stützten sich auf (physisch) externe SD-Karten, die traditionell das Dateisystem der FAT-Familie verwenden, um die Kompatibilität mit den meisten PCs zu gewährleisten (siehe Microsofts Dominanz auf der PC-Welt).
Wenn der interne Speicher größer wurde, wurde dasselbe Dateisystem auf eine interne (immer noch als "externe" bezeichnete) SD-Karte verschoben.
Die Implementierung von FAT / vFAT hatte jedoch zwei Hauptprobleme, die von Google schrittweise behoben wurden:
ioctlsdergleichen FS_IOC_FIEMAP) entwickelt. Somit standen alle Daten auf der SD-Karte allen Apps (da jede Android-App ein UNIX- / Linux-Benutzer ist und eine Benutzer-ID hat) ohne Einschränkungen zur Verfügung, wodurch ernsthafte Bedenken hinsichtlich Datenschutz und Sicherheit aufkommen.Beide Probleme wurden durch Emulation behoben:
/dataPartition (oder eine unabhängige / SD-Karten- Partition auf einigen Geräten zuvor) verschoben, die das ext4Dateisystem enthält (nach und nach durch ersetzt wird f2fs) und die UNIX-Berechtigungen vollständig implementiert. /dataPartition aus zwei weiteren Gründen nicht für den PC verfügbar gemacht werden konnte: (1)Es enthält viele Einstellungen und Anwendungsdaten, die sowohl vor anderen Anwendungen als auch vor menschlichen Benutzern geschützt werden sollen. (2)Linux-Dateisysteme werden von Windows nicht unterstützt. android.process.media) ausgeführt, die im Android-Framework vollständig sandboxed ist und keine eskalierten Aufgaben ausführen kann.Jetzt interagieren die Apps (und MTP, das auch eine App ist) mit dem emulierten Speicher, anstatt /data/mediabeide Zwecke gleichzeitig zu erfüllen, dh Berechtigungsprüfungen unter dem Dateisystem zu erzwingen und wie ein FAT-Dateisystem auf der oberen Oberfläche auszusehen.
Google implementiert jetzt eine Emulation über SD-Karten , um die Mängel von FUSE zu beheben . Ein Hauptfaktor ist der Eingabe- / Ausgabe-Overhead, dh die Verbesserung der Lese- / Schreibgeschwindigkeit.
EXTERNE SPEICHERBESTIMMUNGEN: Das
Konzept der öffentlichen und privaten Dateien auf externem Speicher kann anhand eines Beispiels demonstriert werden:
Termux App installieren.
Erstellen Sie Verzeichnisse /sdcard/Android/data/com.termux/test_dirund /sdcard/test_dir.
Dateien erstellen /sdcard/Android/data/com.termux/test_fileund /sdcard/Android/data/com.termux/test_file.
Führen Sie folgende Befehle aus:
* Sie sollten WhatsApp installiert haben oder den privaten Ordner einer anderen App auswählen.
Erzwinge nun das Stoppen der Termux-App und erteile die Speichererlaubnis . Führen Sie die Befehle erneut aus:
Sehen Sie den Unterschied in den Berechtigungen für dieselben Dateien und Verzeichnisse. Dies scheint ohne Emulation auf einem nativen Linux-Dateisystem nicht einfach möglich zu sein, wenn Hunderte von Apps (Benutzern) gleichzeitig verarbeitet werden müssen. Dies ist die Dateisystememulation, mit der dieselbe Datei unabhängig von den ursprünglichen Berechtigungen für das tatsächliche Dateisystem gleichzeitig mit drei verschiedenen Berechtigungssätzen verfügbar gemacht werden kann:
# 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
Siehe auch Was ist die UID "u # _everybody"?
Verbunden:
FAT-like permission-less filesystem, die in den Anfängen von Android verwendet wurde, um die Abwärtskompatibilität sicherzustellen und die dem Design des externen Speicherkonzepts von Android entspricht. Ich habe eine Bearbeitung vorgenommen, um meinen Standpunkt zu erläutern.