External Storage Technical Information

出處:

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.

外置sdcard可以是物理的也可以是類比的；也可以多個，但只有 主外置sdcard可以通過api訪問。

Device specific configuration

External storage is managed by a combination of the vold init service andMountService system service.

Mounting of physical external storage volumes is handled by vold, whichperforms staging operations to prepare the media before exposing it to apps.The device-specific
vold.fstab configuration 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 should 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 with
  /.
• flags: Optional comma separated list of flags, must not contain
/.Possible values include nonremovable and encryptable.

External storage interactions at and above the framework level are handledthrough
MountService. The device-specific storage_list.xml configurationfile, typically provided through a
frameworks/base overlay, defines theattributes and constraints of storage devices. The
<StorageList> elementcontains one or more <storage> elements, exactly one of which should 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 should 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-specific init.rc service:

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

Where source_path is the backing internal storage and dest_path is thetarget mount point.

通過內建儲存空間可以類比出一個大小寫敏感的有許可權管理的外置儲存空間，通過FUSE daemon實現，如上代碼可以添加到  init_xxx.rc服務中，source_path 是backing internal storage（?內部儲存的部分空間）,dest_path是目標掛載點。

When configuring a device-specific init.rc script, the EXTERNAL_STORAGEenvironment variable must be defined as the path to the primary externalstorage. The
/sdcard path must also resolve to the same location, possiblythrough a symlink. If a device adjusts the location of external storage betweenplatform updates, symlinks should 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 includes a physical SD card assecondary external storage:

• vold.fstab
• storage_list.xml

Access to external storage is protected by various Android permissions.Starting in Android 1.0, write access is protected with theWRITE_EXTERNAL_STORAGE permission, implemented using the
sdcard_rw GID.Starting in Android 4.1, read access is protected with the newREAD_EXTERNAL_STORAGE permission, implemented using the
sdcard_r GID. Toimplement the read permission, a new top-level
/storage directory was created such that processes must hold the sdcard_r GID to traverse into it.

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

訪問外置儲存空間是被android保護的，但各個版本都不同。自android1.0是用WRITE_EXTERNAL_STORAGE許可權，實現是用sdcard_rd組許可權。從android4.1起 讀許可權是用READ_EXTERNAL_STORAGE保護，使用sdcard_r組許可權包含。為了實現這個許可權管理，新的頂層目錄/storage被建立出來，進程必須具有sdcard_r GID才能遍曆它。

因為外置儲存空間無法對 傳統的POSIX檔案系統提供許可權管理等機制，所以系統代碼不該儲存敏感性資料在上面。特別是配置和log檔案等應該只儲存在內部儲存空間上，它們能被有效保護。

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 /sdcard path must resolve to the correct user-specific primary externalstorage based on the user a process is running as.
• Storage for large OBB files in the Android/obb directory 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 daemon atEMULATED_STORAGE_SOURCE, which is hidden from apps. After the Zygote forks,it bind mounts the appropriate user-specific subdirectory from under the FUSEdaemon to
EMULATED_STORAGE_TARGET so 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 as.

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.

自4.2起，裝置可能支援多使用者，外置儲存必須滿足如下條件：

1）每個使用者有獨立的主外置儲存空間，並且相互不能訪問;

2）/sdcard路徑 必須解決 更加不同使用者進程訪問不同使用者的主外置儲存。

3）安裝到外部的apk的lib等檔案在不同使用者間能共用，以作最佳化。

4）第二個外置儲存必須不能被app寫。(包含敏感性資料)。

預設平台實現此功能利用了Linux核心的命名空間為每個zygote的子進程建立獨立的掛載表，利用bind
mounts給每個使用者的主外部儲存空間掛載到私人空間上。??

在啟動間段，系統掛載一個獨立的虛擬外部儲存空間EMULATED_STORAGE_SOURCE，這個對apps是不可見的。當zygote開始建立子進程，他開始從FUSE daemon下bind mounts相應使用者的子檔案夾到
EMULATED_STORAGE_TARGET，這樣解決了對於app來說外部儲存路徑是對的了。而且app只能訪問自己使用者的儲存空間

這個實現也使用共用子樹的核心功能，來廣播從預設的根namespace事件掛載到應用程式的namespace，確保ASEC容器和OBB安裝的功能，繼續正常工作。

它通過開始時掛載rootfs作為共用的，在Zygote的namespace建立後，將其重新掛載作為slave
。