WELCOME TO ANDROID'S EXAMPLE!

External storage is managed by a combination of the vold init service and MountService system servic. Mounting of physical external storage volumes is handled by vold, which performs staging operations to prepare the media before exposing it to apps.
For Android 4.2.2 and earlier, the device-specific vold.fstab configuration file defines mappings from sysfs devices 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 mount point. Separated by spaces, and each must start with /.
  • flags: Optional comma separated list of flags, must not contain /. Possible values include nonremovable and encryptable.
For Android releases 4.3 and later, the various fstab files used by init, vold and recovery were unified in the /fstab.<device> file. For external storage volumes that are managed by vold, the entries should have the following format:

<src> <mnt_point> <type> <mnt_flags> <fs_mgr_flags>
 
  • src: A path under sysfs (usually mounted at /sys) to the device that can provide the mount point. The path must start with /.
  • mount_point: Filesystem path where the volume should be mounted.
  • type: The type of the filesystem on the volume. For external cards, this is usually vfat.
  • mnt_flags: Vold ignores this field and it should be set to defaults
  • fs_mgr_flags: Vold ignores any lines in the unified fstab that do not include the voldmanaged= flag in this field. This flag must be followed by a label describing the card, and a partition number or the word auto. Here is an example: voldmanaged=sdcard:auto. Other possible flags are nonremovable, encryptable=sdcard, and noemulatedsd.
External storage interactions at and above the framework level are handled through MountService. The device-specific storage_list.xml configuration file, typically provided through a frameworks/base overlay, defines the attributes and constraints of storage devices. The <StorageList> element contains one or more <storage> elements, exactly one of which should be marked primary. <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 SD card.
  • 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 free storage. 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 possible implementation is provided by the FUSE daemon in system/core/sdcard, which can be 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 the target mount point.
When configuring a device-specific init.rc script, the EXTERNAL_STORAGE environment variable must be defined as the path to the primary external storage. The /sdcard path must also resolve to the same location, possibly through a symlink. If a device adjusts the location of external storage between platform updates, symlinks should be created so that old paths continue working. Read more...


1 comment:

Popular Posts