Android设备相关配置
2013-11-02 14:31
330 查看
http://source.android.com/devices/tech/storage/index.html
Android supports devices with external storage, which is defined to be a case-insensitive filesystem with immutable POSIX permission classes and modes. External storage can be provided by physical media (such as an SD card), or by exposing a portion of internal storage through an emulation layer(外边存储器可以由物理介质像SD卡或者通过内部存储器的部分空间模拟来提供). Devices may contain multiple instances of external storage.
Access to external storage is protected by various Android permissions. Starting in Android 1.0, write access is protected with the
Starting in Android 4.4, the owner, group and modes of files on external storage devices are now synthesized based on directory structure. This enables apps to manage their package-specific directories on external storage without requiring they hold the broad
Since external storage offers minimal protection for stored data, system code should not store sensitive data on external storage. Specifically, configuration and log files should only be stored on internal storage where they can be effectively protected.(由于外边存储器提供对存储的数据的最小的保护,因此,重要的数据如配置或log应该保存在内部存储器上)
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 at
http://source.android.com/devices/tech/storage/config.html
External storage is managed by a combination of the
For Android 4.2.2 and earlier, the device-specific
For Android releases 4.3 and later, the various fstab files used by init, vold and recovery were unified in the
External storage interactions at and above the framework level are handled through
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
Where
When configuring a device-specific
实际配置例子:
http://source.android.com/devices/tech/storage/config-example.html
Android supports devices with external storage, which is defined to be a case-insensitive filesystem with immutable POSIX permission classes and modes. External storage can be provided by physical media (such as an SD card), or by exposing a portion of internal storage through an emulation layer(外边存储器可以由物理介质像SD卡或者通过内部存储器的部分空间模拟来提供). Devices may contain multiple instances of external storage.
Access to external storage is protected by various Android permissions. Starting in Android 1.0, write access is protected with the
WRITE_EXTERNAL_STORAGEpermission. Starting in Android 4.1, read access is protected with the
READ_EXTERNAL_STORAGEpermission.(要想获得对整个外部存储器的访问权限采用的方法)
Starting in Android 4.4, the owner, group and modes of files on external storage devices are now synthesized based on directory structure. This enables apps to manage their package-specific directories on external storage without requiring they hold the broad
WRITE_EXTERNAL_STORAGEpermission. For example, the app with package name
com.example.foocan now freely access
Android/data/com.example.foo/on external storage devices with no permissions. These synthesized permissions are accomplished by wrapping raw storage devices in a FUSE daemon.(从Android4.4开始,得益于FUSE守护进程的包装,app可以随意访问外边存储器上自己包特定的目录,不需要再申请访问权限)
Since external storage offers minimal protection for stored data, system code should not store sensitive data on external storage. Specifically, configuration and log files should only be stored on internal storage where they can be effectively protected.(由于外边存储器提供对存储的数据的最小的保护,因此,重要的数据如配置或log应该保存在内部存储器上)
Multiple external storage devices
Starting in Android 4.4, multiple external storage devices are surfaced to developers throughContext.getExternalFilesDirs(),
Context.getExternalCacheDirs(), and
Context.getObbDirs(). External storage devices surfaced through these APIs must be a semi-permanent part of the device (such as an SD card slot in a battery compartment). Developers expect data stored in these locations to be available over long periods of time. For this reason, transient storage devices (such as USB mass storage drives) should not be surfaced through these APIs. The
WRITE_EXTERNAL_STORAGEpermission must only grant write access to the primary external storage on a device. Apps must not be allowed to write to secondary external storage devices, except in their package-specific directories as allowed by synthesized permissions. Restricting writes in this way ensures the system can clean up files when applications are uninstalled.
Multi-user external storage
Starting in Android 4.2, devices can support multiple users, and external storage must meet the following constraints: Each user must have their own isolated primary external storage, and must not have access to the primary external storage of other users. The/sdcardpath must resolve to the correct user-specific primary external storage based on the user a process is running as. Storage for large OBB files in the
Android/obbdirectory may be shared between multiple users as an optimization. Secondary external storage must not be writable by apps, except in package-specific directories as allowed by synthesized permissions.
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 at
EMULATED_STORAGE_SOURCE, which is hidden from apps. After the Zygote forks, it bind mounts the appropriate user-specific subdirectory from under the FUSE daemon to
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 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.
http://source.android.com/devices/tech/storage/config.html
External storage is managed by a combination of the
voldinit service and
MountServicesystem service. 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.fstabconfiguration 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
nonremovableand
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:
Voldignores this field and it should be set to
defaults
fs_mgr_flags:
Voldignores 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. (从framework层开始向上与外边设备的交互由MountService负责)The device-specific
storage_list.xmlconfiguration file, typically provided through a
frameworks/baseoverlay, 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.rcservice:(下面是sdcard 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_pathis the backing internal storage and
dest_pathis the target mount point.
When configuring a device-specific
init.rcscript, the
EXTERNAL_STORAGEenvironment variable must be defined as the path to the primary external storage. The
/sdcardpath 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.
实际配置例子:
http://source.android.com/devices/tech/storage/config-example.html
相关文章推荐
- android数据加密传送
- QT5+android_ubuntu软件源
- android无线调试
- Android开源项目之 ActionBarSherlock
- Android开源项目之 SlidingMenu
- Beginning Android 4 Programming Book学习
- 如何在Android模拟器上安装apk文件
- android xliff:g 标签介绍
- Android截取当前屏幕保存到外部设备上
- Android SDK下载和更新失败的解决方法【转】
- android 监听短信(同时监听广播和数据库)
- Android-自定义view中控制屏幕常亮或者定时灭屏
- Android中的bitmap,drawable,canvas以及paint
- Android-反射调用隐藏API
- Android-防止连续点击事件
- Android错误信息分析-No Launcher activity found!
- android 四大组件之--------------Service <二>
- Android 关于倒计时功能的说说
- 关于Android4.x系统默认显示方向各种修改
- Android Activity启动模式的设置