2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
従来のストレージ
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
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 カードスロットなど、デバイスにほぼ固定された部分であることが必要です。デベロッパーは、そのような場所に保存されたデータが長期間にわたって利用されることを想定しています。そのため、一時的なストレージ デバイス(USB マスストレージ ドライブなど)は、これらの API を通じて扱えるようにすることはできません。
WRITE_EXTERNAL_STORAGE
権限で書き込みアクセス権を付与するのは、デバイス上のプライマリ外部ストレージのみである必要があります。アプリでセカンダリ外部ストレージへの書き込みを行うことは許可されません。ただし、パッケージ固有のディレクトリが統合された権限によって許可されている場合は除きます。このような方法で書き込みを制限することで、アプリがアンインストールされた際に、システムによるファイルのクリーンアップが可能となります。
Android 6.0 では、USB フラッシュ ドライブなど、デバイスに短時間接続されるポータブル ストレージ デバイスがサポートされています。ユーザーが新しいポータブル デバイスを挿入すると、プラットフォームがそのデバイスのコンテンツのコピーまたは管理を促す通知を表示します。
Android 6.0 では、取り込まれていないデバイスはポータブル デバイスと見なされます。ポータブル ストレージは短時間しか接続されないため、プラットフォームはメディア スキャンなどの負荷の高いオペレーションを回避します。サードパーティ アプリは、ストレージ アクセス フレームワークを介してポータブル ストレージ上のファイルとやり取りする必要があります。プライバシーとセキュリティ上の理由により、直接のアクセスは明示的にブロックされます。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","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 UTC。"],[],[],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."]]