Di recente, ho capito che se elimino i file da /sdcard/Downloadesso li elimina /storage/emulated/0/Download. E se aggiungo i file in /sdcard/Downloadesso li duplica /storage/emulated/0/Download.
Quindi cos'è /storage/emulated/0/? Per quali scopi lo abbiamo nel nostro file system Android?
Risposte:
/storage/emulated/0/Download è il percorso effettivo dei file.
/sdcard/Download è un collegamento simbolico al percorso effettivo di /storage/emulated/0/Download
Tuttavia, i file effettivi si trovano nel filesystem in /data/media, che viene quindi montato su /storage/emulated/0(e spesso anche su altri mountpoint)
Uno Symlink In informatica, un link simbolico è un termine per qualsiasi file che contiene un riferimento a un altro file o directory sotto forma di un percorso assoluto o relativo e che colpisce la risoluzione percorso. I collegamenti simbolici erano già presenti nel 1978 nei sistemi operativi di minicomputer di DEC e RDOS di Data General.
/storage/emulated/0/è effettivamente /data/media/0/esposto attraverso un filesystem emulato / virtuale, non quello reale.
Questo è in riferimento alla mia precedente risposta qui , ma con dettagli più pertinenti.
Su Android 5 :
/sdcard >S> /storage/emulated/legacy >S> /mnt/shell/emulated/0
/mnt/shell/emulated >E> /data/media
Su 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>per il collegamento simbolico, >E>per l'emulazione e >B>per il bind mount
* USER-IDdell'utente corrente in caso di , Multiple Userso Work Profilenormalmente 0quello del proprietario del dispositivo
* VIEWè uno di read(per app con permesso.READ_EXTERNAL_STORAGE) o write(permesso.WRITE_EXTERNAL_STORAGE) o default(per processi in esecuzione in root / spazio dei nomi di mount globale, cioè al di fuori di zigote)
* Vi erano differenze minori rispetto alle precedenti versioni di Android, ma il concetto di emulazione è stato lo stesso da quando è stato implementato.
* Per ulteriori dettagli sull'implementazione dello spazio dei nomi di mount di Android, vedi questa risposta .
In breve, /sdcarde /storage/emulated/0- che rappresentano un filesystem FAT / vFAT / FAT32 - puntano verso /data/media/0(o /mnt/expand/[UUID]/media/0in caso di Adoptable Storage ) attraverso FUSEo sdcardfsemulazione.
Essendo non specifici di Android ma generalmente correlati a Linux, symlink e bind mount (consultare "Creazione di un bind mount") non rientrano nell'ambito di questa domanda, poiché la domanda riguarda principalmente la parte dell'emulazione.
Perché l'emulazione è qui? Il filesystem emulato è un livello di astrazione sul filesystem reale ( ext4o f2fs) che ha sostanzialmente due scopi:
Leggi il percorso di archiviazione di Android per i dettagli, il riepilogo è:
I primi dispositivi Android erano a corto di memoria interna e si basavano su schede SD (fisicamente) esterne che tradizionalmente utilizzano la famiglia di file system FAT per garantire la compatibilità con la maggior parte dei PC (fare riferimento al dominio di Microsoft sul mondo dei PC).
Quando le dimensioni della memoria interna sono aumentate, lo stesso filesystem è stato spostato sulla scheda SD interna (ancora chiamata "esterna").
Ma l'implementazione FAT / vFAT ha avuto due problemi principali che sono stati affrontati gradualmente da Google:
ioctlssimili FS_IOC_FIEMAP). Quindi, tutti i dati sulla scheda SD erano disponibili per tutte le app (poiché ogni app Android è un utente UNIX / Linux e ha un uid) senza restrizioni, sollevando quindi seri problemi di privacy e sicurezza.Entrambi questi problemi sono stati risolti attraverso l'emulazione:
/datapartizione (o partizione indipendente / sdcard su alcuni dispositivi in precedenza) che contiene il ext4filesystem (gradualmente sostituito da f2fs), implementando completamente le autorizzazioni UNIX. /datanon è stato possibile esporre l' intera partizione al PC per altri 2 motivi: (1)contiene molte impostazioni e dati delle app che devono essere protetti da altre app e dagli utenti umani. (2)I filesystem Linux non sono supportati da Windows. android.process.media) completamente sandbox nel framework Android, non in grado di eseguire attività di escalation.Ora le app (e MTP, che è anche un'app) interagiscono con l'archiviazione emulata anziché /data/media, raggiungendo entrambi gli scopi allo stesso tempo, cioè applicando i controlli delle autorizzazioni sottostanti e assomigliando al filesystem FAT sulla superficie superiore.
Google sta ora implementando l'emulazione tramite sdcardfs per superare le carenze di FUSE ; uno dei principali è l'overhead di input / output, ovvero per migliorare la velocità di lettura / scrittura.
AUTORIZZAZIONI DI MEMORIZZAZIONE ESTERNE: il
concetto di file pubblici e privati su memoria esterna può essere dimostrato usando un esempio:
Installa l'app Termux.
Creare directory /sdcard/Android/data/com.termux/test_dire /sdcard/test_dir.
Creare file /sdcard/Android/data/com.termux/test_filee /sdcard/Android/data/com.termux/test_file.
Eseguire i seguenti comandi:
* Dovresti avere WhatsApp installato o selezionare la cartella privata di qualche altra app.
Ora Forza Arresta l'app Termux e concedi l' autorizzazione di archiviazione . Eseguire nuovamente i comandi:
Vedi la differenza nelle autorizzazioni degli stessi file e directory. Questo sembra non essere semplicemente possibile senza emulazione su un filesystem Linux nativo quando ci sono centinaia di app (utenti) da trattare contemporaneamente. Questa è l'emulazione del file system che consente di esporre lo stesso file con tre diversi set di autorizzazioni contemporaneamente indipendentemente dalle autorizzazioni originali sul file system effettivo:
# 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
Vedi anche Cos'è l'UID "u # _everybody"?
Relazionato:
FAT-like permission-less filesystemche era nei primi giorni di Android per garantire la retrocompatibilità e che soddisfi il design del concetto di archiviazione esterna di Android. Ho fatto una modifica per elaborare il mio punto.