What is /storage/emulated/0/?
Recently, I've figured out that if I delete files from /sdcard/Download
it deletes files from /storage/emulated/0/Download
. And if I add the files into /sdcard/Download
it duplicates them in /storage/emulated/0/Download
.
So what is /storage/emulated/0/
? For what purposes do we have it in our android file system?
storage
migrated from superuser.com Dec 20 '18 at 16:29
This question came from our site for computer enthusiasts and power users.
add a comment |
Recently, I've figured out that if I delete files from /sdcard/Download
it deletes files from /storage/emulated/0/Download
. And if I add the files into /sdcard/Download
it duplicates them in /storage/emulated/0/Download
.
So what is /storage/emulated/0/
? For what purposes do we have it in our android file system?
storage
migrated from superuser.com Dec 20 '18 at 16:29
This question came from our site for computer enthusiasts and power users.
add a comment |
Recently, I've figured out that if I delete files from /sdcard/Download
it deletes files from /storage/emulated/0/Download
. And if I add the files into /sdcard/Download
it duplicates them in /storage/emulated/0/Download
.
So what is /storage/emulated/0/
? For what purposes do we have it in our android file system?
storage
Recently, I've figured out that if I delete files from /sdcard/Download
it deletes files from /storage/emulated/0/Download
. And if I add the files into /sdcard/Download
it duplicates them in /storage/emulated/0/Download
.
So what is /storage/emulated/0/
? For what purposes do we have it in our android file system?
storage
storage
edited Dec 20 '18 at 16:48
xavier_fakerat
7,34151952
7,34151952
asked Dec 20 '18 at 16:22
Nazariy Moshenskiy
23817
23817
migrated from superuser.com Dec 20 '18 at 16:29
This question came from our site for computer enthusiasts and power users.
migrated from superuser.com Dec 20 '18 at 16:29
This question came from our site for computer enthusiasts and power users.
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
/storage/emulated/0/Download
is the actual path to the files.
/sdcard/Download
is a symlink to the actual path of /storage/emulated/0/Download
However, the actual files are located in the filesystem in /data/media
, which is then mounted to /storage/emulated/0
(and often other mountpoints as well)
A Symlink In computing, a symbolic link is a term for any file that contains a reference to another file or directory in the form of an absolute or relative path and that affects pathname resolution. Symbolic links were already present by 1978 in minicomputer operating systems from DEC and Data General's RDOS.
14
This answer would be better if it explained a little bit about why it's "emulated". I believe Android does some hack to fake a FAT fs that's actually backed by something better, but I don't know the details and clicked this question hoping to learn something new.
– R..
Dec 20 '18 at 19:02
2
@R.. the "emulated" IMHO points to the fact that it's an "emulated SD card" (not a real one).
– Izzy♦
Dec 20 '18 at 19:38
8
@R.. It uses SDCardFS. Here's an excellent article about it: xda-developers.com/… (archive)
– Nonny Moose
Dec 21 '18 at 3:16
add a comment |
/storage/emulated/0/
is actually /data/media/0/
exposed through an emulated / virtual filesystem, not the actual one.
This is with reference to my previous answer here, but with more relevant details.
ANDROID STORAGE:
On Android 5:
/sdcard >S> /storage/emulated/legacy >S> /mnt/shell/emulated/0
/mnt/shell/emulated >E> /data/media
On 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>
for symlink, >E>
for emulated and >B>
for bind mount
* USER-ID
of current user in case of Multiple Users
or Work Profile
, normally 0
i.e. 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 minor differences on previous Android versions but the concept of emulation was same ever since implemented.
* For a little bit more details on Android's mount namespace implementation, see this answer.
In short, /sdcard
and /storage/emulated/0
- which represent a FAT/vFAT/FAT32 filesystem - point towards /data/media/0
through FUSE
or sdcardfs
emulation.
Being not Android specific but generally Linux related, symlink and bind mount (see "Creating a bind mount") are out of the scope of this question, as the question is about 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 here the whole story, the summary is:
Early Android devices were short on internal storage and relied on (physically) external SD cards that traditionally use FAT family of filesystem to ensure compatibility with most of the PCs (refer to Microsoft's dominance on PC world).
When the internal storage grew in size, same filesystem was shifted to internal (still called "external") SD card.
But the FAT/vFAT implementation had two major issues which were addressed by Google gradually:
- Android devices were connected to PCs directly (USB Mass Storage) just as we connect a USB drive these days. UMS exposes the device at block level and disconnects the SD card from Android framework (un-mounts), thus making whole data unavailable to apps and possibly breaking many functionalities.
- FAT (being Windows' favorite in development days) was never designed to enforce UNIX permissions (mode, uid, gid) So, all data 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 holdsext4
filesystem (gradually being replaced byf2fs
), fully implementing UNIX permissions. - This design made using UMS impossible because whole
/data
partition could not be 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.(2)
Linux filesystems are not supported by Windows.
So UMS was replaced with Media Transfer Protocol which is a client-server type extension to PTP - an already established protocol. MTP doesn't expose block device but works through software stack. MTP host runs on Android as an app (android.process.media
) fully sandboxed in Android framework, not capable of doing any escalated tasks.
Now the apps (and MTP, which is also an app) interact with emulated storage instead of /data/media
, achieving both purposes at the same time i.e. 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 being 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/Android/data/com.termux/test_file
.
Execute following commands:
* You should have WhatsApp installed or select some other app's private folder.
Now Force Stop the Termux app and grant Storage permission. Execute the commands again:
See the difference in permissions of same files and directories. This seems not to be simply possible without emulation on a native Linux filesystem when there are hundreds of apps (users) to be dealt with simultaneously. This is the filesystem emulation that lets the same file to be exposed with three different sets of permissions at same time independent of it's original permissions on actual filesystem:
# 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
1
+1. I think I misunderstand the part about MTP. Does MTP require a FAT filesystem on the target device to work with? If not, couldn't Google use ext4 filesystem for FUSE implementation as that could also enforce permissions checks needed for an app to access only their data in shared storage?
– Firelord♦
Dec 22 '18 at 6:10
@Firelord when discussing emulation, focus isn't on MTP implementation. Google already made changes to MTP protocol to meet certain Android needs and possibly they could implement it through some native Linux filesystem. But the point is we need aFAT-like permission-less filesystem
that used to be in the early days of Android to ensure backward compatibility and that meets the design of Android's External Storage concept. I've made an edit to elaborate my point.
– Irfan Latif
Dec 22 '18 at 10:41
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "139"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fandroid.stackexchange.com%2fquestions%2f205430%2fwhat-is-storage-emulated-0%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
/storage/emulated/0/Download
is the actual path to the files.
/sdcard/Download
is a symlink to the actual path of /storage/emulated/0/Download
However, the actual files are located in the filesystem in /data/media
, which is then mounted to /storage/emulated/0
(and often other mountpoints as well)
A Symlink In computing, a symbolic link is a term for any file that contains a reference to another file or directory in the form of an absolute or relative path and that affects pathname resolution. Symbolic links were already present by 1978 in minicomputer operating systems from DEC and Data General's RDOS.
14
This answer would be better if it explained a little bit about why it's "emulated". I believe Android does some hack to fake a FAT fs that's actually backed by something better, but I don't know the details and clicked this question hoping to learn something new.
– R..
Dec 20 '18 at 19:02
2
@R.. the "emulated" IMHO points to the fact that it's an "emulated SD card" (not a real one).
– Izzy♦
Dec 20 '18 at 19:38
8
@R.. It uses SDCardFS. Here's an excellent article about it: xda-developers.com/… (archive)
– Nonny Moose
Dec 21 '18 at 3:16
add a comment |
/storage/emulated/0/Download
is the actual path to the files.
/sdcard/Download
is a symlink to the actual path of /storage/emulated/0/Download
However, the actual files are located in the filesystem in /data/media
, which is then mounted to /storage/emulated/0
(and often other mountpoints as well)
A Symlink In computing, a symbolic link is a term for any file that contains a reference to another file or directory in the form of an absolute or relative path and that affects pathname resolution. Symbolic links were already present by 1978 in minicomputer operating systems from DEC and Data General's RDOS.
14
This answer would be better if it explained a little bit about why it's "emulated". I believe Android does some hack to fake a FAT fs that's actually backed by something better, but I don't know the details and clicked this question hoping to learn something new.
– R..
Dec 20 '18 at 19:02
2
@R.. the "emulated" IMHO points to the fact that it's an "emulated SD card" (not a real one).
– Izzy♦
Dec 20 '18 at 19:38
8
@R.. It uses SDCardFS. Here's an excellent article about it: xda-developers.com/… (archive)
– Nonny Moose
Dec 21 '18 at 3:16
add a comment |
/storage/emulated/0/Download
is the actual path to the files.
/sdcard/Download
is a symlink to the actual path of /storage/emulated/0/Download
However, the actual files are located in the filesystem in /data/media
, which is then mounted to /storage/emulated/0
(and often other mountpoints as well)
A Symlink In computing, a symbolic link is a term for any file that contains a reference to another file or directory in the form of an absolute or relative path and that affects pathname resolution. Symbolic links were already present by 1978 in minicomputer operating systems from DEC and Data General's RDOS.
/storage/emulated/0/Download
is the actual path to the files.
/sdcard/Download
is a symlink to the actual path of /storage/emulated/0/Download
However, the actual files are located in the filesystem in /data/media
, which is then mounted to /storage/emulated/0
(and often other mountpoints as well)
A Symlink In computing, a symbolic link is a term for any file that contains a reference to another file or directory in the form of an absolute or relative path and that affects pathname resolution. Symbolic links were already present by 1978 in minicomputer operating systems from DEC and Data General's RDOS.
edited Dec 21 '18 at 9:51
Community♦
1
1
answered Dec 20 '18 at 16:58
Bo Lawson
1,629814
1,629814
14
This answer would be better if it explained a little bit about why it's "emulated". I believe Android does some hack to fake a FAT fs that's actually backed by something better, but I don't know the details and clicked this question hoping to learn something new.
– R..
Dec 20 '18 at 19:02
2
@R.. the "emulated" IMHO points to the fact that it's an "emulated SD card" (not a real one).
– Izzy♦
Dec 20 '18 at 19:38
8
@R.. It uses SDCardFS. Here's an excellent article about it: xda-developers.com/… (archive)
– Nonny Moose
Dec 21 '18 at 3:16
add a comment |
14
This answer would be better if it explained a little bit about why it's "emulated". I believe Android does some hack to fake a FAT fs that's actually backed by something better, but I don't know the details and clicked this question hoping to learn something new.
– R..
Dec 20 '18 at 19:02
2
@R.. the "emulated" IMHO points to the fact that it's an "emulated SD card" (not a real one).
– Izzy♦
Dec 20 '18 at 19:38
8
@R.. It uses SDCardFS. Here's an excellent article about it: xda-developers.com/… (archive)
– Nonny Moose
Dec 21 '18 at 3:16
14
14
This answer would be better if it explained a little bit about why it's "emulated". I believe Android does some hack to fake a FAT fs that's actually backed by something better, but I don't know the details and clicked this question hoping to learn something new.
– R..
Dec 20 '18 at 19:02
This answer would be better if it explained a little bit about why it's "emulated". I believe Android does some hack to fake a FAT fs that's actually backed by something better, but I don't know the details and clicked this question hoping to learn something new.
– R..
Dec 20 '18 at 19:02
2
2
@R.. the "emulated" IMHO points to the fact that it's an "emulated SD card" (not a real one).
– Izzy♦
Dec 20 '18 at 19:38
@R.. the "emulated" IMHO points to the fact that it's an "emulated SD card" (not a real one).
– Izzy♦
Dec 20 '18 at 19:38
8
8
@R.. It uses SDCardFS. Here's an excellent article about it: xda-developers.com/… (archive)
– Nonny Moose
Dec 21 '18 at 3:16
@R.. It uses SDCardFS. Here's an excellent article about it: xda-developers.com/… (archive)
– Nonny Moose
Dec 21 '18 at 3:16
add a comment |
/storage/emulated/0/
is actually /data/media/0/
exposed through an emulated / virtual filesystem, not the actual one.
This is with reference to my previous answer here, but with more relevant details.
ANDROID STORAGE:
On Android 5:
/sdcard >S> /storage/emulated/legacy >S> /mnt/shell/emulated/0
/mnt/shell/emulated >E> /data/media
On 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>
for symlink, >E>
for emulated and >B>
for bind mount
* USER-ID
of current user in case of Multiple Users
or Work Profile
, normally 0
i.e. 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 minor differences on previous Android versions but the concept of emulation was same ever since implemented.
* For a little bit more details on Android's mount namespace implementation, see this answer.
In short, /sdcard
and /storage/emulated/0
- which represent a FAT/vFAT/FAT32 filesystem - point towards /data/media/0
through FUSE
or sdcardfs
emulation.
Being not Android specific but generally Linux related, symlink and bind mount (see "Creating a bind mount") are out of the scope of this question, as the question is about 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 here the whole story, the summary is:
Early Android devices were short on internal storage and relied on (physically) external SD cards that traditionally use FAT family of filesystem to ensure compatibility with most of the PCs (refer to Microsoft's dominance on PC world).
When the internal storage grew in size, same filesystem was shifted to internal (still called "external") SD card.
But the FAT/vFAT implementation had two major issues which were addressed by Google gradually:
- Android devices were connected to PCs directly (USB Mass Storage) just as we connect a USB drive these days. UMS exposes the device at block level and disconnects the SD card from Android framework (un-mounts), thus making whole data unavailable to apps and possibly breaking many functionalities.
- FAT (being Windows' favorite in development days) was never designed to enforce UNIX permissions (mode, uid, gid) So, all data 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 holdsext4
filesystem (gradually being replaced byf2fs
), fully implementing UNIX permissions. - This design made using UMS impossible because whole
/data
partition could not be 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.(2)
Linux filesystems are not supported by Windows.
So UMS was replaced with Media Transfer Protocol which is a client-server type extension to PTP - an already established protocol. MTP doesn't expose block device but works through software stack. MTP host runs on Android as an app (android.process.media
) fully sandboxed in Android framework, not capable of doing any escalated tasks.
Now the apps (and MTP, which is also an app) interact with emulated storage instead of /data/media
, achieving both purposes at the same time i.e. 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 being 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/Android/data/com.termux/test_file
.
Execute following commands:
* You should have WhatsApp installed or select some other app's private folder.
Now Force Stop the Termux app and grant Storage permission. Execute the commands again:
See the difference in permissions of same files and directories. This seems not to be simply possible without emulation on a native Linux filesystem when there are hundreds of apps (users) to be dealt with simultaneously. This is the filesystem emulation that lets the same file to be exposed with three different sets of permissions at same time independent of it's original permissions on actual filesystem:
# 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
1
+1. I think I misunderstand the part about MTP. Does MTP require a FAT filesystem on the target device to work with? If not, couldn't Google use ext4 filesystem for FUSE implementation as that could also enforce permissions checks needed for an app to access only their data in shared storage?
– Firelord♦
Dec 22 '18 at 6:10
@Firelord when discussing emulation, focus isn't on MTP implementation. Google already made changes to MTP protocol to meet certain Android needs and possibly they could implement it through some native Linux filesystem. But the point is we need aFAT-like permission-less filesystem
that used to be in the early days of Android to ensure backward compatibility and that meets the design of Android's External Storage concept. I've made an edit to elaborate my point.
– Irfan Latif
Dec 22 '18 at 10:41
add a comment |
/storage/emulated/0/
is actually /data/media/0/
exposed through an emulated / virtual filesystem, not the actual one.
This is with reference to my previous answer here, but with more relevant details.
ANDROID STORAGE:
On Android 5:
/sdcard >S> /storage/emulated/legacy >S> /mnt/shell/emulated/0
/mnt/shell/emulated >E> /data/media
On 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>
for symlink, >E>
for emulated and >B>
for bind mount
* USER-ID
of current user in case of Multiple Users
or Work Profile
, normally 0
i.e. 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 minor differences on previous Android versions but the concept of emulation was same ever since implemented.
* For a little bit more details on Android's mount namespace implementation, see this answer.
In short, /sdcard
and /storage/emulated/0
- which represent a FAT/vFAT/FAT32 filesystem - point towards /data/media/0
through FUSE
or sdcardfs
emulation.
Being not Android specific but generally Linux related, symlink and bind mount (see "Creating a bind mount") are out of the scope of this question, as the question is about 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 here the whole story, the summary is:
Early Android devices were short on internal storage and relied on (physically) external SD cards that traditionally use FAT family of filesystem to ensure compatibility with most of the PCs (refer to Microsoft's dominance on PC world).
When the internal storage grew in size, same filesystem was shifted to internal (still called "external") SD card.
But the FAT/vFAT implementation had two major issues which were addressed by Google gradually:
- Android devices were connected to PCs directly (USB Mass Storage) just as we connect a USB drive these days. UMS exposes the device at block level and disconnects the SD card from Android framework (un-mounts), thus making whole data unavailable to apps and possibly breaking many functionalities.
- FAT (being Windows' favorite in development days) was never designed to enforce UNIX permissions (mode, uid, gid) So, all data 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 holdsext4
filesystem (gradually being replaced byf2fs
), fully implementing UNIX permissions. - This design made using UMS impossible because whole
/data
partition could not be 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.(2)
Linux filesystems are not supported by Windows.
So UMS was replaced with Media Transfer Protocol which is a client-server type extension to PTP - an already established protocol. MTP doesn't expose block device but works through software stack. MTP host runs on Android as an app (android.process.media
) fully sandboxed in Android framework, not capable of doing any escalated tasks.
Now the apps (and MTP, which is also an app) interact with emulated storage instead of /data/media
, achieving both purposes at the same time i.e. 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 being 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/Android/data/com.termux/test_file
.
Execute following commands:
* You should have WhatsApp installed or select some other app's private folder.
Now Force Stop the Termux app and grant Storage permission. Execute the commands again:
See the difference in permissions of same files and directories. This seems not to be simply possible without emulation on a native Linux filesystem when there are hundreds of apps (users) to be dealt with simultaneously. This is the filesystem emulation that lets the same file to be exposed with three different sets of permissions at same time independent of it's original permissions on actual filesystem:
# 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
1
+1. I think I misunderstand the part about MTP. Does MTP require a FAT filesystem on the target device to work with? If not, couldn't Google use ext4 filesystem for FUSE implementation as that could also enforce permissions checks needed for an app to access only their data in shared storage?
– Firelord♦
Dec 22 '18 at 6:10
@Firelord when discussing emulation, focus isn't on MTP implementation. Google already made changes to MTP protocol to meet certain Android needs and possibly they could implement it through some native Linux filesystem. But the point is we need aFAT-like permission-less filesystem
that used to be in the early days of Android to ensure backward compatibility and that meets the design of Android's External Storage concept. I've made an edit to elaborate my point.
– Irfan Latif
Dec 22 '18 at 10:41
add a comment |
/storage/emulated/0/
is actually /data/media/0/
exposed through an emulated / virtual filesystem, not the actual one.
This is with reference to my previous answer here, but with more relevant details.
ANDROID STORAGE:
On Android 5:
/sdcard >S> /storage/emulated/legacy >S> /mnt/shell/emulated/0
/mnt/shell/emulated >E> /data/media
On 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>
for symlink, >E>
for emulated and >B>
for bind mount
* USER-ID
of current user in case of Multiple Users
or Work Profile
, normally 0
i.e. 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 minor differences on previous Android versions but the concept of emulation was same ever since implemented.
* For a little bit more details on Android's mount namespace implementation, see this answer.
In short, /sdcard
and /storage/emulated/0
- which represent a FAT/vFAT/FAT32 filesystem - point towards /data/media/0
through FUSE
or sdcardfs
emulation.
Being not Android specific but generally Linux related, symlink and bind mount (see "Creating a bind mount") are out of the scope of this question, as the question is about 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 here the whole story, the summary is:
Early Android devices were short on internal storage and relied on (physically) external SD cards that traditionally use FAT family of filesystem to ensure compatibility with most of the PCs (refer to Microsoft's dominance on PC world).
When the internal storage grew in size, same filesystem was shifted to internal (still called "external") SD card.
But the FAT/vFAT implementation had two major issues which were addressed by Google gradually:
- Android devices were connected to PCs directly (USB Mass Storage) just as we connect a USB drive these days. UMS exposes the device at block level and disconnects the SD card from Android framework (un-mounts), thus making whole data unavailable to apps and possibly breaking many functionalities.
- FAT (being Windows' favorite in development days) was never designed to enforce UNIX permissions (mode, uid, gid) So, all data 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 holdsext4
filesystem (gradually being replaced byf2fs
), fully implementing UNIX permissions. - This design made using UMS impossible because whole
/data
partition could not be 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.(2)
Linux filesystems are not supported by Windows.
So UMS was replaced with Media Transfer Protocol which is a client-server type extension to PTP - an already established protocol. MTP doesn't expose block device but works through software stack. MTP host runs on Android as an app (android.process.media
) fully sandboxed in Android framework, not capable of doing any escalated tasks.
Now the apps (and MTP, which is also an app) interact with emulated storage instead of /data/media
, achieving both purposes at the same time i.e. 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 being 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/Android/data/com.termux/test_file
.
Execute following commands:
* You should have WhatsApp installed or select some other app's private folder.
Now Force Stop the Termux app and grant Storage permission. Execute the commands again:
See the difference in permissions of same files and directories. This seems not to be simply possible without emulation on a native Linux filesystem when there are hundreds of apps (users) to be dealt with simultaneously. This is the filesystem emulation that lets the same file to be exposed with three different sets of permissions at same time independent of it's original permissions on actual filesystem:
# 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
/storage/emulated/0/
is actually /data/media/0/
exposed through an emulated / virtual filesystem, not the actual one.
This is with reference to my previous answer here, but with more relevant details.
ANDROID STORAGE:
On Android 5:
/sdcard >S> /storage/emulated/legacy >S> /mnt/shell/emulated/0
/mnt/shell/emulated >E> /data/media
On 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>
for symlink, >E>
for emulated and >B>
for bind mount
* USER-ID
of current user in case of Multiple Users
or Work Profile
, normally 0
i.e. 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 minor differences on previous Android versions but the concept of emulation was same ever since implemented.
* For a little bit more details on Android's mount namespace implementation, see this answer.
In short, /sdcard
and /storage/emulated/0
- which represent a FAT/vFAT/FAT32 filesystem - point towards /data/media/0
through FUSE
or sdcardfs
emulation.
Being not Android specific but generally Linux related, symlink and bind mount (see "Creating a bind mount") are out of the scope of this question, as the question is about 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 here the whole story, the summary is:
Early Android devices were short on internal storage and relied on (physically) external SD cards that traditionally use FAT family of filesystem to ensure compatibility with most of the PCs (refer to Microsoft's dominance on PC world).
When the internal storage grew in size, same filesystem was shifted to internal (still called "external") SD card.
But the FAT/vFAT implementation had two major issues which were addressed by Google gradually:
- Android devices were connected to PCs directly (USB Mass Storage) just as we connect a USB drive these days. UMS exposes the device at block level and disconnects the SD card from Android framework (un-mounts), thus making whole data unavailable to apps and possibly breaking many functionalities.
- FAT (being Windows' favorite in development days) was never designed to enforce UNIX permissions (mode, uid, gid) So, all data 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 holdsext4
filesystem (gradually being replaced byf2fs
), fully implementing UNIX permissions. - This design made using UMS impossible because whole
/data
partition could not be 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.(2)
Linux filesystems are not supported by Windows.
So UMS was replaced with Media Transfer Protocol which is a client-server type extension to PTP - an already established protocol. MTP doesn't expose block device but works through software stack. MTP host runs on Android as an app (android.process.media
) fully sandboxed in Android framework, not capable of doing any escalated tasks.
Now the apps (and MTP, which is also an app) interact with emulated storage instead of /data/media
, achieving both purposes at the same time i.e. 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 being 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/Android/data/com.termux/test_file
.
Execute following commands:
* You should have WhatsApp installed or select some other app's private folder.
Now Force Stop the Termux app and grant Storage permission. Execute the commands again:
See the difference in permissions of same files and directories. This seems not to be simply possible without emulation on a native Linux filesystem when there are hundreds of apps (users) to be dealt with simultaneously. This is the filesystem emulation that lets the same file to be exposed with three different sets of permissions at same time independent of it's original permissions on actual filesystem:
# 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
edited Dec 23 '18 at 13:37
answered Dec 21 '18 at 21:53
Irfan Latif
1,193217
1,193217
1
+1. I think I misunderstand the part about MTP. Does MTP require a FAT filesystem on the target device to work with? If not, couldn't Google use ext4 filesystem for FUSE implementation as that could also enforce permissions checks needed for an app to access only their data in shared storage?
– Firelord♦
Dec 22 '18 at 6:10
@Firelord when discussing emulation, focus isn't on MTP implementation. Google already made changes to MTP protocol to meet certain Android needs and possibly they could implement it through some native Linux filesystem. But the point is we need aFAT-like permission-less filesystem
that used to be in the early days of Android to ensure backward compatibility and that meets the design of Android's External Storage concept. I've made an edit to elaborate my point.
– Irfan Latif
Dec 22 '18 at 10:41
add a comment |
1
+1. I think I misunderstand the part about MTP. Does MTP require a FAT filesystem on the target device to work with? If not, couldn't Google use ext4 filesystem for FUSE implementation as that could also enforce permissions checks needed for an app to access only their data in shared storage?
– Firelord♦
Dec 22 '18 at 6:10
@Firelord when discussing emulation, focus isn't on MTP implementation. Google already made changes to MTP protocol to meet certain Android needs and possibly they could implement it through some native Linux filesystem. But the point is we need aFAT-like permission-less filesystem
that used to be in the early days of Android to ensure backward compatibility and that meets the design of Android's External Storage concept. I've made an edit to elaborate my point.
– Irfan Latif
Dec 22 '18 at 10:41
1
1
+1. I think I misunderstand the part about MTP. Does MTP require a FAT filesystem on the target device to work with? If not, couldn't Google use ext4 filesystem for FUSE implementation as that could also enforce permissions checks needed for an app to access only their data in shared storage?
– Firelord♦
Dec 22 '18 at 6:10
+1. I think I misunderstand the part about MTP. Does MTP require a FAT filesystem on the target device to work with? If not, couldn't Google use ext4 filesystem for FUSE implementation as that could also enforce permissions checks needed for an app to access only their data in shared storage?
– Firelord♦
Dec 22 '18 at 6:10
@Firelord when discussing emulation, focus isn't on MTP implementation. Google already made changes to MTP protocol to meet certain Android needs and possibly they could implement it through some native Linux filesystem. But the point is we need a
FAT-like permission-less filesystem
that used to be in the early days of Android to ensure backward compatibility and that meets the design of Android's External Storage concept. I've made an edit to elaborate my point.– Irfan Latif
Dec 22 '18 at 10:41
@Firelord when discussing emulation, focus isn't on MTP implementation. Google already made changes to MTP protocol to meet certain Android needs and possibly they could implement it through some native Linux filesystem. But the point is we need a
FAT-like permission-less filesystem
that used to be in the early days of Android to ensure backward compatibility and that meets the design of Android's External Storage concept. I've made an edit to elaborate my point.– Irfan Latif
Dec 22 '18 at 10:41
add a comment |
Thanks for contributing an answer to Android Enthusiasts Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fandroid.stackexchange.com%2fquestions%2f205430%2fwhat-is-storage-emulated-0%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown