自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
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 和/或其關係企業的商標或註冊商標。
上次更新時間：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"]],["上次更新時間：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."]]
