¿Qué es / almacenamiento / emulado / 0 /?


40

Recientemente, he descubierto que si elimino archivos de /sdcard/Downloadél, se eliminan los archivos /storage/emulated/0/Download. Y si agrego los archivos /sdcard/Download, los duplica /storage/emulated/0/Download.

Entonces que es /storage/emulated/0/? ¿Para qué fines lo tenemos en nuestro sistema de archivos de Android?

Respuestas:


40

/storage/emulated/0/Download es la ruta real a los archivos.

/sdcard/Download es un enlace simbólico a la ruta real de /storage/emulated/0/Download

Sin embargo, los archivos reales se encuentran en el sistema de archivos /data/media, que luego se monta en /storage/emulated/0(y a menudo también en otros puntos de montaje)

Un enlace simbólico En informática, un enlace simbólico es un término para cualquier archivo que contiene una referencia a otro archivo o directorio en la forma de una ruta absoluta o relativa y que afecta a la resolución nombre de ruta. Los enlaces simbólicos ya estaban presentes en 1978 en los sistemas operativos de minicomputadoras de DEC y RDOS de Data General.


15
Esta respuesta sería mejor si explicara un poco sobre por qué está "emulada". Creo que Android hace algún truco para falsificar un FAT fs que en realidad está respaldado por algo mejor, pero no conozco los detalles e hice clic en esta pregunta con la esperanza de aprender algo nuevo.
R ..

44
@R .. el IMHO "emulado" apunta al hecho de que es una "tarjeta SD emulada" (no una real).
Izzy

10
@R .. Utiliza SDCardFS. Aquí hay un excelente artículo al respecto: xda-developers.com/… ( archivo )
Nonny Moose

16

/storage/emulated/0/en realidad está /data/media/0/expuesto a través de un sistema de archivos emulado / virtual, no el actual.

Esto es con referencia a mi respuesta anterior aquí , pero con detalles más relevantes.

ALMACENAMIENTO DE ANDROID:

En Android 5 :

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

En 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>para enlace simbólico, >E>para >B>montaje emulado y de enlace
* USER-IDdel usuario actual en caso de , Multiple Userso Work Profilenormalmente el 0propietario del dispositivo
* VIEWes uno de read(para aplicaciones con permiso.READ_EXTERNAL_STORAGE) o write(permiso.WRITE_EXTERNAL_STORAGE) o default(para procesos que se ejecutan en la raíz / espacio de nombres de montaje global, es decir, fuera del cigoto)
* Hubo pequeñas diferencias en las versiones anteriores de Android, pero el concepto de emulación fue el mismo desde que se implementó.
* Para obtener un poco más de detalles sobre la implementación del espacio de nombres de montaje de Android, consulte esta respuesta .

En resumen, /sdcardy /storage/emulated/0- que representan una FAT / VFAT / FAT32 sistema de archivos - punto hacia /data/media/0(o /mnt/expand/[UUID]/media/0en caso de adoptable de almacenamiento ) a través de FUSEo sdcardfsemulación.

Al no ser específico de Android, sino generalmente relacionado con Linux, el enlace simbólico y el montaje de enlace (consulte "Creación de un montaje de enlace") están fuera del alcance de esta pregunta, ya que la pregunta se refiere principalmente a la parte de emulación.

EMULACIÓN:

¿Por qué la emulación está aquí? El sistema de archivos emulado es una capa de abstracción en el sistema de archivos real ( ext4o f2fs) que sirve básicamente para dos propósitos:

  • Retenga la conectividad USB de los dispositivos Android a las PC (implementado a través de MTP ahora por días)
  • Restringir el acceso no autorizado de aplicaciones / procesos a los medios de comunicación privados del usuario y los datos de otras aplicaciones en la tarjeta SD.

Leer viaje de almacenamiento de Android para obtener más información, el resumen es:

Los primeros dispositivos Android estaban cortos de almacenamiento interno y se basó en (físicamente) tarjetas SD externas que utilizan tradicionalmente familia de sistema de archivos FAT para garantizar la compatibilidad con la mayoría de los PC (se refieren al dominio de Microsoft en el mundo del PC).
Cuando el almacenamiento interno creció en tamaño, el mismo sistema de ficheros se cambió a (aún llamado "externa") tarjeta SD interna.
Sin embargo, la aplicación FAT / VFAT tenía dos grandes cuestiones que fueron abordadas por Google poco a poco:

  • Los dispositivos Android se conectaron directamente a las PC ( almacenamiento masivo USB ) tal como conectamos una unidad USB en estos días. UMS expone el dispositivo a nivel de bloque y desconecta la tarjeta SD del marco de Android (se desmonta), lo que hace que toda la información no esté disponible para las aplicaciones y posiblemente rompa muchas funcionalidades.
  • FAT (siendo el favorito de Windows en los días de desarrollo) nunca fue diseñado para imponer permisos UNIX (modo, uid, gid y enlaces simbólicosioctls similares , y similares FS_IOC_FIEMAP). Por lo tanto, todos los datos en la tarjeta SD estaban disponibles para todas las aplicaciones (ya que cada aplicación de Android es un usuario de UNIX / Linux y tiene un uid) sin restricciones, lo que plantea serias preocupaciones de privacidad y seguridad.

Ambos problemas se abordaron mediante la emulación:

  • El almacenamiento real de la tarjeta SD se movió a la /datapartición (o partición independiente / tarjeta sd en algunos dispositivos anteriormente) que contiene el ext4sistema de archivos (reemplazado gradualmente por f2fs), implementando completamente los permisos UNIX.
  • Este diseño hizo que el uso de UMS fuera imposible porque la /datapartición completa no podía exponerse a la PC por 2 razones más: (1)contiene una gran cantidad de configuraciones y datos de aplicaciones que deben protegerse de otras aplicaciones y de usuarios humanos. (2)Los sistemas de archivos de Linux no son compatibles con Windows.
    Por lo tanto, UMS se reemplazó con el Protocolo de transferencia de medios, que es una extensión de tipo cliente-servidor para PTP, un protocolo ya establecido. MTP no expone el dispositivo de bloque, pero funciona a través de la pila de software. El host MTP se ejecuta en Android como una aplicación ( android.process.media) totalmente aislada en el marco de Android, no capaz de realizar ninguna tarea escalada.

Ahora las aplicaciones (y MTP, que también es una aplicación) interactúan con el almacenamiento emulado en lugar de hacerlo /data/media, logrando ambos propósitos al mismo tiempo, es decir, haciendo cumplir las verificaciones de permisos debajo y pareciendo un sistema de archivos FAT en la superficie superior.

Google ahora está implementando la emulación a través de sdcardfs para superar las deficiencias de FUSE ; Uno de los principales es la sobrecarga de entrada / salida, es decir, para mejorar las velocidades de lectura / escritura.

PERMISOS DE ALMACENAMIENTO EXTERNO: El
concepto de archivos públicos y privados en el almacenamiento externo se puede demostrar con un ejemplo:
Instalar la aplicación Termux.
Crear directorios /sdcard/Android/data/com.termux/test_diry /sdcard/test_dir.
Crear archivos /sdcard/Android/data/com.termux/test_filey /sdcard/Android/data/com.termux/test_file.
Ejecute los siguientes comandos:

sin_almacenamiento_perm * Debería tener instalado WhatsApp o seleccionar la carpeta privada de alguna otra aplicación.

Ahora Force Stop the Termux app y otorgue permiso de almacenamiento . Ejecute los comandos nuevamente:

with_storage_perm

Vea la diferencia en los permisos de los mismos archivos y directorios. Esto parece no ser simplemente posible sin la emulación en un sistema de archivos Linux nativo cuando hay cientos de aplicaciones (usuarios) que se deben tratar simultáneamente. Esta es la emulación del sistema de archivos que permite exponer el mismo archivo con tres conjuntos diferentes de permisos al mismo tiempo, independientemente de sus permisos originales en el sistema de archivos real:

# 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

Consulte también ¿Qué es el UID "u # _everybody"?

Relacionado:


2
+1. Creo que no entiendo la parte sobre MTP. ¿MTP requiere un sistema de archivos FAT en el dispositivo de destino para trabajar? Si no, ¿no podría Google usar el sistema de archivos ext4 para la implementación de FUSE, ya que eso también podría hacer cumplir las verificaciones de permisos necesarias para que una aplicación acceda solo a sus datos en el almacenamiento compartido?
Señor del fuego

1
@Firelord cuando se habla de emulación, el foco no está en la implementación de MTP. Google ya realizó cambios en el protocolo MTP para satisfacer ciertas necesidades de Android y posiblemente podrían implementarlo a través de algún sistema de archivos nativo de Linux. Pero el punto es que necesitamos una FAT-like permission-less filesystemque solía ser en los primeros días de Android para garantizar la compatibilidad con versiones anteriores y que cumpla con el diseño del concepto de almacenamiento externo de Android. Hice una edición para elaborar mi punto.
Irfan Latif
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.