2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
アプリ サンドボックス
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android プラットフォームでは、アプリケーション リソースの識別と隔離のために Linux ユーザーベースの保護を利用しています。これにより、アプリが互いに隔離され、悪意のあるアプリからアプリやシステムが保護されます。これを行うために、Android は各 Android アプリに固有のユーザー ID(UID)を割り当て、独自のプロセスで実行します。
Android では、UID を使用してカーネルレベルのアプリ サンドボックスをセットアップします。カーネルは、アプリに割り当てられたユーザー ID やグループ ID といった標準的な Linux の機能を通して、アプリとシステムの間にプロセスレベルでセキュリティを提供します。デフォルトでは、アプリは相互にやり取りできず、OS へのアクセスが制限されています。アプリ A がアプリ B のデータを読み取ったり、許可なく電話をかけたりといった悪意のある動作をしようとしても、適切なデフォルトのユーザー権限がないため阻止されます。サンドボックスはシンプルで監査可能であり、数十年の実績を持つ UNIX 形式のユーザーごとのプロセス分離とファイル権限に基づいています。
アプリ サンドボックスはカーネル内にあるため、このセキュリティ モデルはネイティブ コードと OS アプリの両方にまで及びます。OS ライブラリ、アプリ フレームワーク、アプリ ランタイム、すべてのアプリなど、カーネル上にあるすべてのソフトウェアは、アプリ サンドボックス内で動作します。一部のプラットフォームでは、デベロッパーは特定の開発フレームワーク、API セット、言語に制約されることがあります。Android の場合、セキュリティを適用する必要があるアプリの記述方法に制限はありません。この点で、ネイティブ コードは解釈済みのコードと同じくらいサンドボックス化されています。
保護
通常、適切に構成されたデバイスのアプリ サンドボックスから抜け出すには、Linux カーネルのセキュリティを侵害する必要があります。ただし、他のセキュリティ機能と同様に、アプリ サンドボックスに適用される個々の保護も完璧ではないため、単一の脆弱性を突かれて OS や他のアプリが侵害されないようにするための多層防御が重要になります。
Android では数多くの保護機能を使用して、アプリ サンドボックスを強化しています。こうした保護機能は時間をかけて導入され、元からある UID ベースの任意アクセス制御(DAC)サンドボックスを大幅に強化してきました。以前の Android リリースには次の保護機能が含まれていました。
- Android 5.0 では、SELinux の強制アクセス制御(MAC)によるシステムとアプリの分離が導入されました。ただし、すべてのサードパーティ アプリが同じ SELinux コンテキスト内で実行されたため、アプリ間の分離は主に UID DAC によって行われました。
- Android 6.0 では、SELinux サンドボックスが拡張され、物理的なユーザーごとの境界を越えてアプリが分離されるようになりました。さらに、Android ではアプリデータの安全なデフォルト値も設定されています。
targetSdkVersion >= 24
のアプリでは、アプリのホーム ディレクトリのデフォルトの DAC 権限が 751 から 700 に変更されました。これにより、個人のアプリデータのデフォルトの安全性が向上しました(ただし、アプリはこのデフォルト値をオーバーライドできます)。
- Android 8.0 では、すべてのアプリが、アプリが使用を許可されたシステムコールを制限する
seccomp-bpf
フィルタを使用して実行するように設定され、アプリとカーネルの境界が強化されました。
- Android 9 では、
targetSdkVersion >=
28
のすべての非特権アプリが個々の SELinux サンドボックスで動作する必要があるため、アプリごとに MAC が提供されます。この保護機能により、アプリの分離状態が改善され、安全なデフォルト値がオーバーライドされることを防ぎ、アプリのデータに自由にアクセスできないようにします。
- Android 10 では、アプリに対してファイル システムの raw データのビューが制限されており、/sdcard/DCIM などのパスに直接アクセスできません。ただし、アプリは Context.getExternalFilesDir() などの適用可能なメソッドにより返されたパッケージ固有のパスに対しては、引き続き完全な raw アクセスを行うことができます。
ファイルの共有に関するガイドライン
どこからでもアプリデータにアクセスできるように設定することは、セキュリティ上おすすめできません。すべてのユーザーにアクセス権が付与されるため、目的の受信者のみにアクセスを制限することができません。この方法は、情報漏洩や Confused deputy(混乱した使節)の脆弱性につながり、機密性の高いデータを扱うアプリ(メール クライアントなど)を狙う不正なソフトウェアにとって格好の標的となります。Android 9 以降では、このような方法でファイルを共有することは targetSdkVersion>=28
のアプリでは明示的に禁止されています。
ファイルを共有する際には、どこからでもアプリデータにアクセスできるようにする代わりに、次のガイドラインを参考にしてください。
- アプリが別のアプリとファイルを共有する必要がある場合は、コンテンツ プロバイダを使用してください。コンテンツ プロバイダは適切な粒度でデータを共有しますが、どこからでもアクセス可能な UNIX 権限に付随する多くのマイナス面はありません(詳細については、コンテンツ プロバイダの基本をご覧ください)。
- どうしても外部に公開する必要のあるファイル(写真など)がアプリに存在する場合は、メディア固有の形式(写真、動画、音声ファイルのみ)にして、MediaStore クラスを使用して保存する必要があります(メディア アイテムを追加する方法について詳しくは、共有ストレージからメディア ファイルにアクセスするをご覧ください)。
ストレージの実行時の権限は、MediaStore を介して、強く型付けされたコレクションへのアクセスを制御します。PDF などの弱く型付けされたファイルや MediaStore.Downloads クラスにアクセスする場合、アプリは ACTION_OPEN_DOCUMENT
インテントなどのインテントを使用する必要があります。
Android 10 の動作を有効にするには、requestLegacyExternalStorage
マニフェスト属性を使用し、アプリの権限に関するおすすめの設定に沿って設定します。
- Android 9(以前)を対象とするアプリの場合、マニフェスト フラグのデフォルト値は
true
です。
- Android 10 を対象とするアプリのデフォルト値は false です。Android 10 を対象とするアプリで、フィルタ表示されたストレージ ビューを一時的に無効にするには、マニフェスト フラグの値を
true
に設定します。
- インストーラは制限付きの権限を使用して、サンドボックス化されていないストレージに対して許可されているアプリを許可リストに登録します。許可リストに登録されていないアプリはサンドボックス化されません。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-06-12 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-06-12 UTC。"],[],[],null,["# Application Sandbox\n\nThe Android platform takes advantage of the Linux user-based protection to\nidentify and isolate app resources. This isolates apps from each other and\nprotects apps and the system from malicious apps. To do this, Android assigns a\nunique user ID (UID) to each Android app and runs it in its own\nprocess.\n\nAndroid uses the UID to set up a kernel-level Application Sandbox. The\nkernel enforces security between apps and the system at the process level\nthrough standard Linux facilities such as user and group IDs that are assigned\nto apps. By default, apps can't interact with each other and have limited\naccess to the OS. If app A tries to do something malicious, such as read\napp B's data or dial the phone without permission, it's prevented from\ndoing so because it doesn't have the appropriate default user privileges. The\nsandbox is simple, auditable, and based on decades-old UNIX-style user\nseparation of processes and file permissions.\n\nBecause the Application Sandbox is in the kernel, this security model\nextends to both native code and OS apps. All of the software above the\nkernel, such as OS libraries, app framework, app runtime, and\nall apps, run within the Application Sandbox. On some platforms,\ndevelopers are constrained to a specific development framework, set of APIs, or\nlanguage. On Android, there are no restrictions on how an app can be\nwritten that are required to enforce security; in this respect, native code is\nas sandboxed as interpreted code.\n\nProtections\n-----------\n\n\nGenerally, to break out of the Application Sandbox in a properly configured\ndevice, one must compromise the security of the Linux kernel. However, similar\nto other security features, individual protections enforcing the app\nsandbox are not invulnerable, so defense-in-depth is important to prevent\nsingle vulnerabilities from leading to compromise of the OS or other apps.\n\n\nAndroid relies on a number of protections to enforce the app\nsandbox. These enforcements have been introduced over time and have\nsignificantly strengthened the original UID-based discretionary access control\n(DAC) sandbox. Previous Android releases included the following\nprotections:\n\n- In Android 5.0, SELinux provided mandatory access control (MAC) separation between the system and apps. However, all third-party apps ran within the same SELinux context so inter-app isolation was primarily enforced by UID DAC.\n- In Android 6.0, the SELinux sandbox was extended to isolate apps across the per-physical-user boundary. In addition, Android also set safer defaults for app data: For apps with `targetSdkVersion \u003e= 24`, default DAC permissions on an app's home dir changed from 751 to 700. This provided safer default for private app data (although apps can override these defaults).\n- In Android 8.0, all apps were set to run with a `seccomp-bpf` filter that limited the syscalls that apps were allowed to use, thus strengthening the app/kernel boundary.\n- In Android 9 all nonprivileged apps with `targetSdkVersion \u003e=\n 28` must run in individual SELinux sandboxes, providing MAC on a per-app basis. This protection improves app separation, prevents overriding safe defaults, and (most significantly) prevents apps from making their data world accessible.\n- In Android 10 apps have a limited raw view of the filesystem, with no direct access to paths like /sdcard/DCIM. However, apps retain full raw access to their package-specific paths, as returned by any applicable methods, such as [Context.getExternalFilesDir()](https://developer.android.com/reference/android/content/Context.html#getExternalFilesDir(jav%20a.lang.String)).\n\nGuidelines for sharing files\n----------------------------\n\nSetting app data as world accessible is a poor security practice. Access\nis granted to everyone and it's not possible to limit access to only the intended\nrecipient(s). This practice has led to information disclosure leaks and confused\ndeputy vulnerabilities, and is a favorite target for malware that targets apps\nwith sensitive data (such as email clients). In Android 9 and higher, sharing\nfiles this way is explicitly disallowed for apps with\n`targetSdkVersion\u003e=28`.\n\n\nInstead of making app data world-accessible, use the following guidelines\nwhen sharing files:\n\n- If your app needs to share files with another app, use a [content provider](https://developer.android.com/guide/topics/providers/content-provider-basics.html). Content providers share data with the proper granularity and without the many downsides of world-accessible UNIX permissions (for details, refer to [Content provider basics](https://developer.android.com/guide/topics/providers/content-provider-basics.html)).\n- If your app has files that genuinely should be accessible to the world (such as photos), they must be media-specific (photos, videos, and audio files only) and stored using the [MediaStore](https://developer.android.com/reference/android/provider/MediaStore) class. (For more details on how to add a media item, see [Access media files from shared storage](https://developer.android.com/training/data-storage/shared/media#add-item).)\n\nThe **Storage** runtime permission controls access\nto strongly-typed collections through **MediaStore** .\nFor accessing weakly typed files such as PDFs and the [MediaStore.Downloads](https://developer.android.com/reference/android/provider/MediaStore.Downloads) class, apps must use\nintents like the [`ACTION_OPEN_DOCUMENT`](https://developer.android.com/reference/android/content/Intent.html#ACTION_OPEN_DOCUMENT) intent.\n\nTo enable Android 10 behavior, use the\n[requestLegacyExternalStorage](https://developer.android.com/training/data-storage/files/external-scoped#opt-out-of-%20filtered-view) manifest\nattribute, and follow [App permissions best practices](https://developer.android.com/training/permissions/usage-notes).\n\n- The manifest flag default value is `true` for apps targeting Android 9 and lower.\n- The default value is false for apps targeting Android 10. To temporarily opt out of the filtered storage view in apps targeting Android 10, set the manifest flag's value to `true`.\n- Using restricted permissions, the installer allowlists apps permitted for nonsandboxed storage. Nonallowlisted apps are sandboxed."]]