Storage Emulated Adalah

/storage/emulated/0/
is actually
/information/media/0/
exposed through an emulated / virtual filesystem, not the actual one.

This is with reference to my previous answer hither, merely with more relevant details.

ANDROID STORAGE:

On Android 5:

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

On Android vi+:

        # for (Coffee) Android apps (running inside zygote virtual machine) # "/storage to VIEW" demark mount is within a separate mount namespace for every app /sdcard >S> /storage/self/primary /storage/self >B> /mnt/user/USER-ID /mnt/user/USER-ID/primary >Due south> /storage/emulated/USER-ID /storage/emulated >B> /mnt/runtime/VIEW/emulated /mnt/runtime/VIEW/emulated >Due east> /data/media  # for services/daemons/processes in root/global namespace (VIEW = default) /sdcard >S> /storage/cocky/primary /storage >B> /mnt/runtime/default /mnt/runtime/default/self/primary >S> /mnt/user/USER-ID/primary /mnt/user/USER-ID/chief >S> /storage/emulated/USER-ID /storage/emulated >B> /mnt/runtime/default/emulated /mnt/runtime/default/emulated >E> /data/media
        
      

<sup>*
>S>
for symlink,
>E>
for emulated and
>B>
for bind mountain

*
USER-ID
of electric current user in example of
Multiple Users
or
Work Profile, usually

i.east. that of device owner

*
VIEW
is one of
read
(for apps with permission.READ_EXTERNAL_STORAGE) or
write
(permission.WRITE_EXTERNAL_STORAGE) or
default
(for processes running in root/global mount namespace i.e. outside zygote)

* There were small differences on previous Android versions but the concept of emulation was same ever since implemented.

* For a little bit more details on Android’s mountain namespace implementation, run across this respond.</sup>

In brusque,
/sdcard
and
/storage/emulated/0
– which represent a Fatty/vFAT/FAT32 filesystem – signal towards
/data/media/0
(or
/mnt/expand/[UUID]/media/0
in example of Adoptable Storage) through
FUSE
or
sdcardfs
emulation.

Beingness non Android specific just by and large Linux related, symlink and bind mount (see “Creating a bind mountain”) are out of the scope of this question, every bit the question is nigh emulation part mainly.

EMULATION:

Why the emulation is here? Emulated filesystem is an abstraction layer on actual filesystem (ext4
or
f2fs) that serves basically two purposes:

• Retain USB connectivity of Android devices to PCs (implemented through MTP now a days)
• Restrict unauthorized access of apps/processes to user’s private media and other apps’ data on SD card.

Read Android’s Storage Journey for details, the summary is:

Early on Android devices were curt on internal storage and relied on (physically) external SD cards that traditionally utilise FAT family of filesystem to ensure compatibility with about of the PCs (refer to Microsoft’s dominance on PC world).
When the internal storage grew in size, same filesystem was shifted to internal (withal called “external”) SD menu.
But the FAT/vFAT implementation had two major problems which were addressed by Google gradually:

• Android devices were continued to PCs directly (USB Mass Storage) just equally we connect a USB drive these days. UMS exposes the device at block level and disconnects the SD card from Android framework (united nations-mounts), thus making whole data unavailable to apps and possibly breaking many functionalities.
• FAT (being Windows’ favorite in evolution days) was never designed to enforce UNIX permissions (style, uid, gid and likewise symlinks, and
  ioctls
  like
  FS_IOC_FIEMAP). So, all information on SD card was available to all apps (since every Android app is a UNIX/Linux user and has a uid) with no restrictions, hence raising serious privacy and security concerns.

Both of these issues were addressed through emulation:

• Actual SD card storage was moved to
  /data
  partition (or independent /sdcard partition on some devices previously) which holds
  ext4
  filesystem (gradually existence replaced past
  f2fs), fully implementing UNIX permissions.
• This design made using UMS incommunicable considering whole
  /data
  partition could non exist exposed to PC for 2 more reasons:
  (1)
  it contains a lot of settings and apps’ data which is to be protected from other apps as well as human users.
  (ii)
  Linux filesystems are not supported by Windows.
  So UMS was replaced with Media Transfer Protocol which is a customer-server type extension to PTP – an already established protocol. MTP doesn’t expose cake device merely works through software stack. MTP host runs on Android as an app (android.procedure.media) fully sandboxed in Android framework, non capable of doing any escalated tasks.

Now the apps (and MTP, which is likewise an app) interact with emulated storage instead of
/data/media, achieving both purposes at the same time i.due east. enforcing permission checks underneath and looking like Fat filesystem on upper surface.

Google is now implementing emulation through sdcardfs to overcome shortcomings of FUSE; one major beingness the input/output overhead i.e. to improve read/write speeds.

EXTERNAL STORAGE PERMISSIONS:

Concept of Public and Private files on external storage can be demonstrated using an example:
Install Termux app.
Create directories
/sdcard/Android/data/com.termux/test_dir
and
/sdcard/test_dir.
Create files
/sdcard/Android/data/com.termux/test_file
and
/sdcard/test_file.
Execute following commands:

^{* You should have WhatsApp installed or select another app’southward individual binder.}

Now Force Terminate the Termux app and grant Storage permission. Execute the commands over again:

Run across the difference in permissions of aforementioned files and directories. This seems not to exist simply possible without emulation on a native Linux filesystem when there are hundreds of apps (users) to exist dealt with simultaneously. This is the filesystem emulation that lets the same file to be exposed with three different sets of permissions at aforementioned time independent of information technology’southward original permissions on bodily filesystem:

        # affect /data/media/0/test_file  # stat -c '%a %u %g %n' /information/media/0/test_file 644 1023 1023 /information/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
        
      

Also see What is the “u#_everybody” UID?

Related:

• Why is the ‘storage/emulated/’ directory inaccessible?
• How can I brand a symlink (or equivalent) inside /storage/emulated/0?