自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
傳統儲存空間
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Android 支援傳統儲存裝置,這類裝置定義為不區分大小寫的檔案系統,並具有不可變動的 POSIX 權限類別和模式。傳統儲存空間的概念涵蓋模擬和可攜式儲存空間。可攜式儲存空間的定義是指系統未
採用的任何外部儲存空間,因此未經過格式化和加密,或未與特定裝置綁定。由於傳統外部儲存空間無法為儲存的資料提供足夠保護,因此系統程式碼不應將機密資料儲存在外部儲存空間。具體來說,設定和記錄檔應只儲存在可有效保護的內部儲存空間中。
多使用者外部儲存空間
從 Android 4.2 開始,裝置可支援多位使用者,外部儲存空間必須符合下列限制:
- 每位使用者都必須擁有自己的隔離主外部儲存空間,且不得存取其他使用者的主外部儲存空間。
/sdcard
路徑必須根據執行程序的使用者,解析為正確的使用者專屬主要外部儲存空間。
Android/obb
目錄中的大型 OBB 檔案儲存空間可供多位使用者共用,以利最佳化。
- 應用程式不得寫入次要外部儲存空間,但可寫入由合成權限允許的套件專屬目錄。
這項功能的預設平台實作方式會利用 Linux 核心命名空間,為每個 Zygote 分支程序建立獨立的掛載表,然後使用繫結掛載點,在該私人命名空間中提供正確的使用者專屬主要外部儲存空間。
在啟動時,系統會在 EMULATED_STORAGE_SOURCE
中掛接單一模擬外部儲存空間 FUSE 守護程序,並隱藏在應用程式中。Zygote 分支後,會將 FUSE 守護程式底下的適當使用者專屬子目錄繫結至 EMULATED_STORAGE_TARGET
,以便為應用程式正確解析外部儲存空間路徑。由於應用程式缺少其他使用者儲存空間的可用掛載點,因此只能存取啟動該應用程式的使用者儲存空間。
這個實作方式還會使用共用子樹核心功能,將掛載事件從預設根命名空間傳播至應用程式命名空間,確保 ASEC 容器和 OBB 掛載功能繼續正常運作。方法是將 rootfs 掛載為共用,然後在建立每個 Zygote 命名空間後,將其重新掛載為從屬。
多個外部儲存裝置
自 Android 4.4 起,開發人員可透過 Context.getExternalFilesDirs()
、Context.getExternalCacheDirs()
和 Context.getObbDirs()
取得多個外部儲存裝置。
透過這些 API 顯示的外部儲存空間裝置,必須是裝置的半永久性部分 (例如電池隔間中的 SD 卡插槽)。開發人員預期儲存在這些位置的資料可長時間使用。因此,請勿透過這些 API 顯示暫時性儲存裝置 (例如 USB 大量儲存裝置)。
WRITE_EXTERNAL_STORAGE
權限只能授予裝置上主要外部儲存空間的寫入權限。應用程式不得寫入次要外部儲存空間裝置,但可寫入合成權限允許的套件專屬目錄。以這種方式限制寫入作業,可確保系統在解除安裝應用程式時能清除檔案。
Android 6.0 支援可攜式儲存裝置,也就是僅連接裝置一段時間的裝置,例如 USB 隨身碟。使用者插入新行動裝置時,平台會顯示通知,讓使用者複製或管理該裝置的內容。
在 Android 6.0 中,任何未採用的裝置都會視為可攜式裝置。由於可攜式儲存裝置的連線時間很短,因此平台會避免執行媒體掃描等繁重作業。第三方應用程式必須透過 Storage Access Framework 與可攜式儲存空間中的檔案互動;基於隱私權和安全性考量,直接存取權已明確遭到封鎖。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。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,["# Traditional storage\n\nAndroid supports devices with traditional storage, which is defined to be a\ncase-insensitive filesystem with immutable POSIX permission classes and modes.\nThe notion of traditional storage encompasses emulated and portable storage.\nPortable storage is defined as any external storage that is not [adopted](/docs/core/storage/adoptable) by the\nsystem and therefore not formatted and encrypted or tied to a specific device.\nBecause traditional external storage offers minimal protection for stored data,\nsystem code should not store sensitive data on external storage. Specifically,\nconfiguration and log files should only be stored on internal storage where\nthey can be effectively protected.\n\nMulti-user external storage\n---------------------------\n\nStarting in Android 4.2, devices can support multiple users, and external\nstorage must meet the following constraints:\n\n- Each user must have their own isolated primary external storage, and must not have access to the primary external storage of other users.\n- The `/sdcard` path must resolve to the correct user-specific primary external storage based on the user a process is running as.\n- Storage for large OBB files in the `Android/obb` directory may be shared between multiple users as an optimization.\n- Secondary external storage must not be writable by apps, except in package-specific directories as allowed by synthesized permissions.\n\nThe default platform implementation of this feature leverages Linux kernel\nnamespaces to create isolated mount tables for each Zygote-forked process,\nand then uses bind mounts to offer the correct user-specific primary external\nstorage into that private namespace.\n\nAt boot, the system mounts a single emulated external storage FUSE daemon\nat `EMULATED_STORAGE_SOURCE`, which is hidden from apps. After\nthe Zygote forks, it bind mounts the appropriate user-specific subdirectory\nfrom under the FUSE daemon to `EMULATED_STORAGE_TARGET` so that\nexternal storage paths resolve correctly for the app. Because an app lacks\naccessible mount points for other users' storage, they can only access\nstorage for the user it was started as.\n\nThis implementation also uses the shared subtree kernel feature to\npropagate mount events from the default root namespace into app namespaces,\nwhich ensures that features like ASEC containers and OBB mounting continue\nworking correctly. It does this by mounting the rootfs as shared, and then\nremounting it as slave after each Zygote namespace is created.\n\nMultiple external storage devices\n---------------------------------\n\nStarting in Android 4.4, multiple external storage devices are surfaced\nto developers through `Context.getExternalFilesDirs()`,\n`Context.getExternalCacheDirs()`, and\n`Context.getObbDirs()`.\n\n\u003cbr /\u003e\n\nExternal 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.\n\n\u003cbr /\u003e\n\nThe `WRITE_EXTERNAL_STORAGE` permission must only grant write\naccess to the primary external storage on a device. Apps must not be\nallowed to write to secondary external storage devices, except in their\npackage-specific directories as allowed by synthesized\npermissions. Restricting writes in this way ensures the system can clean\nup files when applications are uninstalled.\n\nUSB media support\n-----------------\n\nAndroid 6.0 supports portable storage devices which are only connected to the\ndevice for a short period of time, like USB flash drives. When a user inserts a\nnew portable device, the platform shows a notification to let them copy or\nmanage the contents of that device.\n\nIn Android 6.0, any device that is not adopted is considered portable. Because\nportable storage is connected for only a short time, the platform avoids heavy\noperations such as media scanning. Third-party apps must go through the [Storage Access Framework](https://developer.android.com/guide/topics/providers/document-provider.html) to interact with files on portable storage; direct access is explicitly\nblocked for privacy and security reasons."]]