External Storage technical information

Source:

Http://source.android.com/tech/storage/

External Storage technical information

Android supports devices with external storage, which is defined to be acase-insensitive and permissionless filesystem. external Storage can beprovided by physical media (such as an SD card), or by an emulation layer backedby internal storage. devices may
Contain multiple instances of externalstorage, but currently only the primary external storage is exposed todevelopers through API.

External sdcards can be physical or simulated, or multiple, but only the primary external sdcard can be accessed through APIS.

Device specific configuration

External Storage is managed by a combination ofvoldInit service andMountServiceSystem Service.

Mounting of physical external storage volumes is handledvold, Whichperforms staging operations to prepare the media before exposing it to apps. The device-specific
vold.fstabConfiguration file defines mappings from sysfsdevices to filesystem mount points, and each line follows this format:

dev_mount <label> <mount_point> <partition> <sysfs_path> [flags]

• label: Label for the volume.
• mount_point: Filesystem path where the volume shocould be mounted.
• partition: Partition Number (1 based), or 'auto' for first usable partition.
• sysfs_path: One or more sysfs paths to devices that can provide this mountpoint. Separated by spaces, and each must start
  /.
• flags: Optional comma separated list of flags, must not contain
/. Possible values includenonremovableAndencryptable.

External Storage interactions at and above the framework level are handledthrough
MountService. The device-specificstorage_list.xmlConfigurationfile, typically provided through
frameworks/baseOverlay, defines theattributes and constraints of storage devices.
<StorageList>Elementcontains one or more<storage>Elements, exactly one of which shocould be markedprimary.
<storage>Attributes include:

• mountPoint: Filesystem path of this mount.
• storageDescription: String resource that describes this mount.
• primary: True if this mount is the primary external storage.
• removable: True if this mount has removable media, such as a physical sdcard.
• emulated: True if this mount is emulated and is backed by internal storage, possibly using a fuse daemon.
• mtp-reserve: Number of MB of storage that MTP shoshould reserve for freestorage. only used when Mount is marked as emulated.
• allowMassStorage: True if this mount can be shared via USB Mass Storage.
• maxFileSize: Maximum File Size in MB.

Devices may provide external storage by emulating a case-insensitive, permissionless filesystem backed by internal storage. One possibleimplementation is provided by the fuse daemon in
system/core/sdcard, Which canbe added as a device-specificinit.rcService:

# virtual sdcard daemon running as media_rw (1023)service sdcard /system/bin/sdcard <source_path> <dest_path> 1023 1023    class late_start

Wheresource_pathIs the backing internal storage anddest_pathIs thetarget mount point.

The built-in memory can be used to simulate a case-sensitive external memory with the permission to manage. It is implemented through fuse daemon. The above code can be added to the init_xxx.rc service. The source_path is backing internal storage (? And dest_path is the target mount point.

When processing ing a device-specificinit.rcScript,EXTERNAL_STORAGEEnvironment variable must be defined as the path to the primary externalstorage.
/sdcardPath must also resolve to the same location, possiblythrough a symlink. If a device adjusts the location of External Storage betweenplatform updates, symlinks shoshould be created so that old paths continue working.

As an example, here's the storage configuration for xoom, which uses a fusedaemon to provide primary external storage, and between des a physical SD card assecondary External Storage:

• Vold. fstab
• Storage_list.xml

Access to external storage is protected by varous Android permissions. Starting in Android 1.0, write access is protected withWRITE_EXTERNAL_STORAGEPermission, implemented using
sdcard_rwGID. Starting in Android 4.1, read access is protected with the newREAD_EXTERNAL_STORAGEPermission, implemented using
sdcard_rGID. toimplement the read permission, a new top-level
/storageDirectory was created such that processes must holdsdcard_rGID to traverse into it.

Since external storage offers no support for traditional POSIX filesystempermissions, system code shocould not store sensitive data on external storage. Specifically, configuration and log files shocould only be stored on internalstorage where they can be too tively
Protected.

Access to external memory is protected by Android, but each version is different. Auto-android1.0 is usedWRITE_EXTERNAL_STORAGEPermission to use the sdcard_rd group permission. Read Permission from android4.1 is usedREAD_EXTERNAL_STORAGEProtection, including permissions using sdcard_r group. To implement this permission management, the new top-level directory/storage is created, and the process must have sdcard_r GID to traverse it.

Because external memory cannot provide permission management and other mechanisms to the traditional POSIX file system, the system code should not store sensitive data on it. In particular, configurations and log files should be stored only in internal storage, which can be effectively protected.

Multi-User External Storage

Starting in Android 4.2, devices can support multiple users, and externalstorage must meet the following constraints:

• Each user must have their own isolated primary external storage, and must nothave access to the primary external storage of other users.
• The/sdcardPath must resolve to the correct user-specific primary externalstorage based on the user a process is running.
• Storage for large OBB files inAndroid/obbDirectory may be sharedbetween multiple users as an optimization.
• Secondary external storage must not be writable by apps.

The default platform implementation of this feature leverages Linux kernel namespaces to create isolated Mount tables for each zygote-Forked process, and then uses bind mounts to offer the correct user-specific primary external storage into that private
Namespace.

At boot, the system mounts a single emulated external storage fuse daemonEMULATED_STORAGE_SOURCE, Which is hidden from apps. After the zygote forks, it bind mounts the appropriate user-specific subdirectory from under the fusedaemon
EMULATED_STORAGE_TARGETSo that external storage paths resolve correctly for the app. Because an app lacks accessible mount points for other users 'Storage, they can only access storage for the user it was started.

This implementation also uses the shared subtree kernel feature to propagate Mount events from the default root namespace into app namespaces, which ensures that features like ASEC containers and OBB mounting continue working correctly. it does this by mounting
The rootfs as shared, and then remounting it as slave after each zygote namespace is created.

Since 4.2, the device may support multiple users. External Storage must meet the following requirements:

1) each user has an independent primary external storage and cannot access each other;

2) The/sdcard path must solve the problem of accessing the primary and external storage of different users by different user processes.

3) files such as lib installed on the external APK can be shared among different users for optimization.

4) The second external storage must not be written by the app. (Including sensitive data ).

By default, the platform enables this function to create independent Mount tables for each zygote sub-process using the Linux kernel namespace and bind
Mounts mounts each user's primary external storage space to a private space .??

In the boot period, the system mounts an independent virtual external storage space.EMULATED_STORAGE_SOURCEThis is invisible to apps. When zygote starts to create a sub-process, it starts from the BIND mounts sub-folder of the corresponding user under fuse daemon
EMULATED_STORAGE_TARGETIn this way, the external storage path for the app is correct. In addition, the app can only access the buckets of its own users.

This implementation also uses the kernel function of the shared subtree to broadcast the mounting from the default root namespace event to the namespace of the application. This ensures that the ASEC container and the OBB installation function continue to work normally.

It mounts rootfs as a shared object at the beginning. After the namespace of zygote is created, it is remounted as a server Load balancer instance.
.