自 2025 年 3 月 27 日起，我们建议您使用 android-latest-release 而非 aosp-main 构建 AOSP 并为其做出贡献。如需了解详情，请参阅 AOSP 的变更。
Storage
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Android 一直在不断发展，以期支持各种存储设备类型和功能。所有 Android 版本均支持配有传统存储空间（包括便携式存储空间和模拟存储空间）的设备。便携式存储空间是指物理介质（例如 SD 卡或 USB 设备），用于进行临时数据传输/文件存储。物理介质可以随设备一起保留更长时间，但并非固定在设备上，可以移除。自 Android 1.0 开始，SD 卡已可用作便携式存储；Android 6.0 增加了对 USB 的支持。模拟存储空间可通过将部分内部存储空间暴露于模拟层来实现，从 Android 3.0 开始便已支持此功能。
从 Android 6.0 开始，Android 支持可合并的存储设备，这种存储设备是指可以像内部存储设备那样进行加密和格式化的物理介质（例如 SD 卡或 USB 设备）。可合并的存储设备可存储各类应用数据。
权限
对外部存储设备的访问受各种 Android 权限的保护。
从 Android 1.0 开始，采用 WRITE_EXTERNAL_STORAGE 权限保护写入访问。从 Android 4.1 开始，采用 READ_EXTERNAL_STORAGE 权限保护读取访问。
从 Android 4.4 开始，外部存储设备上的文件所有者、组和模式根据目录结构合成。这样，应用可在外部存储设备上管理其文件包专用目录，而无需获得广泛的 WRITE_EXTERNAL_STORAGE 权限。
例如，文件包名称为 com.example.foo 的应用现在无需任何权限，即可自由访问外部存储设备上的 Android/data/com.example.foo/。通过将原始存储设备封装在 FUSE 守护进程中，可实现此类合成权限。
从 Android 10 开始，以 Android 9 及更低版本为目标平台的应用默认使用旧版存储空间，并且可以选择使用隔离存储空间。
以 Android 10 为目标平台并默认使用隔离存储空间的应用可以暂时选择停用隔离存储空间。可使用控制存储模型的清单属性 requestLegacyExternalStorage 更改默认状态。
由于 READ_EXTERNAL_STORAGE 和 WRITE_EXTERNAL_STORAGE 权限均受到软性限制，因此，如果安装程序未将应用列入白名单，则权限仅能控制对听觉和视觉集合的访问，而无权访问 SD 卡。即使在应用请求访问旧版存储空间时，也同样如此。如需详细了解硬性限制和软性限制，请参阅 Android 10 中的硬性限制和软性限制。
如果安装程序将该权限列入白名单，则以旧模式运行的应用将获得非隔离权限行为。该权限可控制 SD 卡访问权限，以及听觉和视觉集合。如果应用以 Android 9 或更低版本为目标平台且未选择使用隔离存储空间，或者以 Android 10 为目标平台且选择停用隔离存储空间，就会出现这种情况。
白名单状态只能在安装时指定，并且在应用安装完成后才能更改。
如需详细了解如何设置 READ_EXTERNAL_STORAGE 权限，请参阅
PackageInstaller.SessionParams 类中的
setWhitelistedRestrictedPermissions()。
Android 13 引入了细化的媒体权限，以支持访问由其他应用创建的媒体文件的应用。应用必须请求细化的媒体权限中列出的一项或多项细化的媒体权限，而不是 READ_EXTERNAL_STORAGE 权限。
Android 14 基于精细媒体权限构建，可让用户在应用请求媒体权限时授予对其可视化媒体库的部分访问权限。如需了解详情，请参阅授予对照片和视频的部分访问权限。
运行时权限
Android 6.0 引入了一种新的运行时权限模式，在该模式下，应用可在运行时根据需要请求各项功能。由于新模式包含 READ/WRITE_EXTERNAL_STORAGE 权限，因此平台需要动态授予存储空间访问权限，同时无需终止或重启已在运行的应用。通过为所有已安装的存储设备维护以下三个不同视图，可实现该模式：
/mnt/runtime/default，向无特殊存储空间权限的应用以及 adbd 和其他系统组件所在的根命名空间显示/mnt/runtime/read，向具有 READ_EXTERNAL_STORAGE 的应用显示（针对 Android 10 设置 LEGACY_STORAGE）/mnt/runtime/write，向具有 WRITE_EXTERNAL_STORAGE 的应用显示
在创建 Zygote 分支时，我们会为各运行应用创建装载命名空间，并将相应的初始视图挂载到位。稍后，在授予运行时权限后，vold 将跳转到已在运行应用的装载命名空间，并将升级后的视图挂载到位。请注意，权限降级定会导致应用被终止。
用于实现此特性的 setns() 功能至少需要运行 Linux 3.8，但补丁已成功向后移植至 Linux 3.4。PermissionsHostTest CTS 测试可用于验证内核行为是否正确。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-07-27。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-07-27。"],[],[],null,["# Storage\n\nAndroid has evolved over time to support a wide variety of storage device\ntypes and features. All versions of Android support devices with\n[traditional storage](/docs/core/storage/traditional), which includes\nportable and emulated storage. *Portable* storage can be provided by\nphysical media, like an SD card or USB, that is for temporary data transfer/\nfile storage. The physical media may remain with the device for an extended\nperiod of time, but is not tied to the device and may be removed. SD cards have\nbeen available as portable storage since Android 1.0; Android 6.0 added USB\nsupport. *Emulated* storage is provided by exposing a portion of\ninternal storage through an emulation layer and has been available since\nAndroid 3.0.\n\nStarting in Android 6.0, Android supports [*adoptable* storage](/docs/core/storage/adoptable), which is\nprovided by physical media, like an SD card or USB, that is encrypted and\nformatted to behave like internal storage. Adoptable storage can store all\ntypes of application data.\n\nPermissions\n-----------\n\nAccess to external storage is protected by various Android permissions.\nStarting in Android 1.0, write access is protected with the\n`WRITE_EXTERNAL_STORAGE` permission. Starting in Android 4.1, read\naccess is protected with the `READ_EXTERNAL_STORAGE` permission.\n\nStarting in Android 4.4, the owner, group and modes of files on external\nstorage devices are now synthesized based on directory structure. This enables\napps to manage their package-specific directories on external storage without\nrequiring they hold the broad `WRITE_EXTERNAL_STORAGE` permission.\nFor example, the app with package name `com.example.foo` can now\nfreely access `Android/data/com.example.foo/` on external storage\ndevices with no permissions. These synthesized permissions are accomplished by\nwrapping raw storage devices in a FUSE daemon.\n\nStarting in Android 10, apps that target Android 9\nand lower default to legacy storage, and can *opt in* to isolated storage.\nApps that target Android 10 and default to isolated\nstorage can *temporarily opt out* of it. Use the manifest attribute\n[requestLegacyExternalStorage](https://developer.android.com/reference/android/R.attr.html#requestLegacyExternalStorage),\nwhich controls the storage model, to change the default state.\n\nSince both `READ_EXTERNAL_STORAGE` and\n`WRITE_EXTERNAL_STORAGE` permissions are\nsoft-restricted, if the installer didn't whitelist the app, the\npermission controls access to the aural and visual collections\nonly, with no access to the SD card. This applies even if the app\nrequests legacy storage. For more information about both hard\nrestrictions and soft restrictions, see\n[Hard and soft restrictions in Android 10](/docs/core/permissions/runtime_perms#hardRestrictions).\n\nIf the installer whitelisted the permission, an app running in legacy mode\ngets the nonisolated permission behavior. The permission controls SD card access, and the aural\nand visual collections. This happens when either the app targets Android 9 or\nlower and doesn't opt in to isolated storage, or it targets Android 10 and opts out.\n\nThe whitelist state can be specified only at install time, and\ncan't be changed until the app has been installed.\n\nFor more information on setting the `READ_EXTERNAL_STORAGE`\npermission, see [setWhitelistedRestrictedPermissions()](https://developer.android.com/reference/android/content/pm/PackageInstaller.SessionParams#setWhitelistedRestrictedPermissions(java.util.Set%3Cjava.lang.String%3E)) in the [PackageInstaller.SessionParams](https://developer.android.com/reference/android/content/pm/PackageInstaller.SessionParams) class.\n\nAndroid 13 introduces granular media permissions to support apps that\naccess media files created by other apps. Apps must request one or more of the granular\nmedia permissions listed in [Granular media permissions](https://developer.android.com/about/versions/13/behavior-changes-13#granular-media-permissions) instead of the `READ_EXTERNAL_STORAGE` permission.\n\nAndroid 14 builds on [granular media permissions](https://developer.android.com/about/versions/13/behavior-changes-13#granular-media-permissions) to allow users to\ngrant partial access to their visual media library when apps request media permissions. See [Grant partial access to photos and videos](https://developer.android.com/about/versions/14/changes/partial-photo-video-access) for more information.\n\n### Runtime permissions\n\nAndroid 6.0 introduces a new [runtime permissions](/docs/core/permissions/runtime_perms) model where\napps request capabilities when needed at runtime. Because the new model\nincludes the `READ/WRITE_EXTERNAL_STORAGE` permissions, the platform\nneeds to dynamically grant storage access without killing or restarting\nalready-running apps. It does this by maintaining three distinct views of all\nmounted storage devices:\n\n- `/mnt/runtime/default` is shown to apps with no special storage permissions, and to the root namespace where `adbd` and other system components live.\n- `/mnt/runtime/read` is shown to apps with `READ_EXTERNAL_STORAGE` (Set `LEGACY_STORAGE` for Android 10)\n- `/mnt/runtime/write` is shown to apps with `WRITE_EXTERNAL_STORAGE`\n\nAt Zygote fork time, we create a mount namespace for each running app and\nbind mount the appropriate initial view into place. Later, when runtime\npermissions are granted, `vold` jumps into the mount namespace of\nalready-running apps and bind mounts the upgraded view into place. Note that\npermission downgrades always result in the app being killed.\n\nThe `setns()` functionality used to implement this feature\nrequires at least Linux 3.8, but patches have been backported successfully to\nLinux 3.4. The `PermissionsHostTest` CTS test can be used to verify\ncorrect kernel behavior."]]
