55 votos

¿Qué es /storage/emulated/0/?

Recientemente, he descubierto que si borro los archivos de /sdcard/Download que borra los archivos de /storage/emulated/0/Download . Y si añado los archivos en /sdcard/Download los duplica en /storage/emulated/0/Download .

Entonces, ¿qué es /storage/emulated/0/ ? ¿Con qué propósito lo tenemos en nuestro sistema de archivos de androides?

52voto

rascalking Puntos 1422

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

/sdcard/Download es un vínculo simbólico con el camino real de /storage/emulated/0/Download

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

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

17 votos

Esta respuesta sería mejor si explicara un poco por qué se "emula". Creo que Android hace algún hack para fingir una FAT fs que en realidad está respaldado por algo mejor, pero no sé los detalles y clic en esta pregunta con la esperanza de aprender algo nuevo.

4 votos

@R.. el "emulado" IMHO apunta a que es una "tarjeta SD emulada" (no una real).

10 votos

@R.. Utiliza SDCardFS. Aquí hay un excelente artículo sobre ello: xda-developers.com/ ( archivo )

21voto

Jack Wade Puntos 231

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

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

Android ALMACENAMIENTO:

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 symlink, >E> para emular y >B> para el montaje de bind
* USER-ID del usuario actual en caso de Multiple Users o Work Profile Normalmente 0 es decir, el del propietario del dispositivo
* VIEW es uno de los read (para aplicaciones con permiso.ALMACENAMIENTO_EXTERNO_LECTURA) o write (permiso.ALMACENAMIENTO_EXTERNO_ESCRIPCIÓN) o default (para los procesos que se ejecutan en el espacio de nombres Root/global mount, es decir, fuera del cigoto)
* Hubo pequeñas diferencias con respecto a las anteriores Android pero el concepto de emulación fue el mismo desde que se implementó.
* Para un poco más de detalles sobre Android de la implementación del espacio de nombres de la montaña, mira esto responder a .

En resumen, /sdcard y /storage/emulated/0 - que representan un sistema de archivos FAT/vFAT/FAT32 - apuntan hacia /data/media/0 a través de FUSE o sdcardfs emulación.

No siendo Android específico pero generalmente relacionado con Linux, symlink y monte de unión (véase "Creación de una montura de unión") están fuera del alcance de esta pregunta, ya que se trata de la parte de emulación principalmente.

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 ( ext4 o f2fs ) que sirve básicamente para dos propósitos:

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

Lea aquí el toda la historia el resumen es:

Temprano Android Los dispositivos tenían poca capacidad de almacenamiento interno y dependían de tarjetas SD externas (físicamente) que tradicionalmente utilizan la familia de sistemas de archivos FAT para garantizar la compatibilidad con la mayoría de los PC (véase el dominio de Microsoft en el mundo de los PC).
Cuando el almacenamiento interno creció en tamaño, el mismo sistema de archivos se cambió a una tarjeta SD interna (aún llamada "externa").
Pero la implementación del FAT/vFAT tuvo dos problemas importantes que fueron abordados por Google gradualmente:

  • Android los dispositivos se conectaron a los PCs directamente ( Almacenamiento masivo USB ) al igual que conectamos una unidad USB en estos días. UMS expone el dispositivo a nivel de bloque y desconecta la tarjeta SD de Android (un-mounts), lo que hace que los datos completos no estén disponibles 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 hacer cumplir los permisos de UNIX (modo, uid, gid) Por lo tanto, todos los datos de la tarjeta SD estaban disponibles para todas las aplicaciones (ya que cada Android app es un usuario de UNIX/Linux y tiene un uid) sin restricciones, lo que plantea serias preocupaciones de privacidad y seguridad.

Ambas cuestiones se abordaron mediante la emulación:

  • El almacenamiento real de la tarjeta SD fue trasladado a /data (o una partición independiente de /sdcard en algunos dispositivos anteriormente) que contiene ext4 sistema de archivos (siendo reemplazado gradualmente por f2fs ), aplicando plenamente los permisos de UNIX.
  • Este diseño hizo que el uso de la UMS fuera imposible porque todo /data La partición no podía ser expuesta al PC por 2 razones más: (1) contiene una gran cantidad de configuraciones y datos de aplicaciones que deben ser protegidas de otras aplicaciones así como de usuarios humanos. (2) Los sistemas de archivos de Linux no son compatibles con Windows.
    Así que UMS fue reemplazado por el Protocolo de Transferencia de Medios, que es una extensión de tipo cliente-servidor a PTP - un protocolo ya establecido. MTP no expone el dispositivo de bloqueo, sino que funciona a través de la pila de software. El host MTP se ejecuta en Android como una aplicación ( android.process.media ) completamente en caja de arena en Android marco de trabajo, no es capaz de hacer ninguna tarea escalonada.

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

Google está implementando la emulación a través de sdcardfs para superar las deficiencias de FUSE uno de los principales es la entrada/salida de los gastos generales, es decir, para mejorar la velocidad de lectura/escritura.

EXTERNAL STORAGE PERMISSIONS:
El concepto de Archivos públicos y privados en almacenamiento externo puede demostrarse con un ejemplo:
Instalar la aplicación Termux.
Crear directorios /sdcard/Android/data/com.termux/test_dir y /sdcard/test_dir .
Crear archivos /sdcard/Android/data/com.termux/test_file y /sdcard/Android/data/com.termux/test_file .
Ejecute los siguientes comandos:

without_storage_perm * Debes tener WhatsApp instalado o seleccionar la carpeta privada de alguna otra aplicación.

Ahora Fuerza Detener la aplicación de Termux y conceder Permiso de almacenamiento . Ejecute los comandos de nuevo:

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 nativo de Linux cuando hay cientos de aplicaciones (usuarios) a tratar simultáneamente. Esta es la emulación del sistema de archivos que permite que el mismo archivo sea expuesto con tres conjuntos de permisos diferentes 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

2 votos

+1. Creo que no he entendido bien la parte del MTP. ¿Requiere MTP un sistema de archivos FAT en el dispositivo de destino para funcionar? Si no es así, ¿no podría Google utilizar el sistema de archivos ext4 para la implementación de FUSE, ya que también podría aplicar las comprobaciones de permisos necesarias para que una aplicación acceda sólo a sus datos en el almacenamiento compartido?

1 votos

@Firelord cuando se habla de emulación, no se centra en la implementación de MTP. Google ya hizo 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 un FAT-like permission-less filesystem que solía ser en los primeros días de Android para garantizar la compatibilidad con versiones anteriores y que cumple con el diseño del concepto de almacenamiento externo de Android. He hecho una edición para elaborar mi punto.

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X