Actual SD card storage was moved to /data partition (or independent /sdcard partition on some devices previously) which holds ext4 filesystem (gradually being replaced by f2fs), fully implementing UNIX permissions.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.īoth of these issues were addressed through emulation: FAT (being Windows' favorite in development days) was never designed to enforce UNIX permissions (mode, uid, gid and likewise symlinks, and ioctls like FS_IOC_FIEMAP).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. Android devices were connected to PCs directly ( USB Mass Storage) just as we connect a USB drive these days.When the internal storage grew in size, same filesystem was shifted to internal (still called "external") SD card.īut the FAT/vFAT implementation had two major issues which were addressed by Google gradually: Read Android's Storage Journey for details, the summary is:Įarly 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). Restrict unauthorized access of apps/processes to user's private media and other apps' data on SD card.Retain USB connectivity of Android devices to PCs (implemented through MTP now a days).Why the emulation is here? Emulated filesystem is an abstraction layer on actual filesystem ( ext4 or f2fs) that serves basically two purposes: In short, /sdcard and /storage/emulated/0 - which represent a FAT/vFAT/FAT32 filesystem - point towards /data/media/0 (or /mnt/expand//media/0 in case of Adoptable Storage) through FUSE or sdcardfs emulation.īeing 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. * For a little bit more details on Android's mount namespace implementation, see this answer. * There were minor differences on previous Android versions but the concept of emulation was same ever since implemented. * 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. * USER-ID of current user in case of Multiple Users or Work Profile, normally 0 i.e. * >S> for symlink, >E> for emulated and >B> for bind mount mnt/runtime/default/emulated >E> /data/media storage/emulated >B> /mnt/runtime/default/emulated mnt/runtime/default/self/primary >S> /mnt/user/USER-ID/primary # for services/daemons/processes in root/global namespace (VIEW = default) mnt/runtime/VIEW/emulated >E> /data/media storage/emulated >B> /mnt/runtime/VIEW/emulated mnt/user/USER-ID/primary >S> /storage/emulated/USER-ID # "/storage to VIEW" bind mount is inside a separate mount namespace for every app On Android 6+: # for (Java) Android apps (running inside zygote virtual machine) On Android 5: /sdcard >S> /storage/emulated/legacy >S> /mnt/shell/emulated/0 This is with reference to my previous answer here, but with more relevant details. storage/emulated/0/ is actually /data/media/0/ exposed through an emulated / virtual filesystem, not the actual one.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |