2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main ではなく android-latest-release を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
Storage
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android は、さまざまなストレージ デバイスの種類と機能に対応するため、時間とともに進化してきました。Android のすべてのバージョンで、ポータブル ストレージとエミュレートされたストレージを含む従来のストレージを備えたデバイスをサポートします。ポータブル ストレージは、SD カードや USB などの物理メディアによって提供され、一時的なデータ転送やファイル保存に使用されます。物理メディアは長時間デバイスに接続したままにすることもありますが、デバイスには結合されておらず、取り外しが可能です。SD カードは Android 1.0 以降でポータブル ストレージとして利用できます。USB のサポートは Android 6.0 で追加されました。エミュレートされたストレージは、内部ストレージの一部をエミュレーション レイヤを通じて公開することで提供され、Android 3.0 以降で利用できます。
Android 6.0 以降、Android では Adoptable Storage をサポートするようになりました。これは、SD カードや USB などの物理メディアによって提供され、暗号化とフォーマットを行ったうえで内部ストレージと同様に動作するストレージです。Adoptable Storage には、あらゆる種類のアプリデータを保存できます。
権限
外部ストレージへのアクセスは、さまざまな 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 デーモン内の RAW ストレージ デバイスをラップすることで実現されます。
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 権限ではなく、きめ細かいメディア権限の一覧に記載されたきめ細かいメディア権限を 1 つ以上リクエストする必要があります。
Android 14 ではきめ細かいメディア権限を利用して、アプリがメディア権限をリクエストした場合に、ユーザーがビジュアル メディア ライブラリへの部分的なアクセスを付与できるようにしています。詳細は写真と動画への部分的なアクセス権を付与するをご覧ください。
実行時の権限
Android 6.0 では、新しい実行時の権限モデルが導入されました。これは、アプリが実行時に必要に応じて機能をリクエストするものです。新しいモデルには READ/WRITE_EXTERNAL_STORAGE 権限が含まれているため、プラットフォームでは、すでに実行中のアプリを強制終了または再起動することなく、ストレージ アクセスを動的に付与する必要があります。これは、マウントされたすべてのストレージ デバイスの 3 つの異なるビューを維持することで実現されます。
/mnt/runtime/default は、特別なストレージ権限を持たないアプリと、adbd および他のシステム コンポーネントが稼働しているルート名前空間に対して表示されます。/mnt/runtime/read は、READ_EXTERNAL_STORAGE を持つアプリ（LEGACY_STORAGE を Android 10 用に設定）に対して表示されます。/mnt/runtime/write は、WRITE_EXTERNAL_STORAGE を持つアプリに対して表示されます。
Zygote でのフォーク時には、実行中のアプリごとにマウント名前空間が作成され、適切な初期ビューが所定の場所にバインド マウントされます。その後、実行時の権限が付与されると、vold はすでに実行中のアプリのマウント名前空間にジャンプし、アップグレードされたビューを所定の場所にバインド マウントします。権限のダウングレードは、常にアプリの強制終了を発生させることに注意してください。
この機能を実装するために使用される setns() 関数は Linux 3.8 以上を必要としますが、パッチは Linux 3.4 に問題なくバックポートされています。PermissionsHostTest CTS テストを使用すると、カーネル動作が正常かどうかを確認できます。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。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,["# 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."]]
