自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
应用沙盒
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Android 平台利用基于用户的 Linux 保护机制识别和隔离应用资源,可将不同的应用分隔开来,并保护应用和系统免受恶意应用的攻击。为此,Android 会为每个 Android 应用分配一个唯一的用户 ID (UID),并在自己的进程中运行。
Android 会使用该 UID 设置一个内核级应用沙盒。内核会在进程级别利用标准的 Linux 机制(例如,分配给应用的用户 ID 和组 ID)实现应用和系统之间的安全防护。默认情况下,应用不能彼此交互,而且对操作系统的访问权限会受到限制。如果应用 A 尝试执行恶意操作(例如在没有权限的情况下读取应用 B 的数据或拨打电话),系统会阻止此类行为,因为应用 A 没有相应的默认用户权限。这一沙盒机制非常简单,可审核,并且基于已有数十年历史的 UNIX 风格的进程用户隔离和文件权限机制。
由于应用沙盒位于内核层面,因此该安全模型的保护范围扩展到了原生代码和操作系统应用。位于内核之上的所有软件(例如,操作系统库、应用框架、应用运行时和所有应用)都会在应用沙盒中运行。某些平台会限制开发者只能使用特定的开发框架、API 或语言。在 Android 上,并没有为了强制执行安全防护机制而限制开发者必须如何编写应用;在这方面,原生代码与解释型代码一样会被沙盒化。
保护机制
通常,为了在经过适当配置的设备上攻破应用沙盒这道防线,必须先攻破 Linux 内核的安全功能。但是,与其他安全功能类似,强制执行应用沙盒的各种保护机制并非无懈可击,因此纵深防御对于防止通过单个漏洞入侵操作系统或其他应用而言非常重要。
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 中,应用的文件系统的原始视图有限,且无法直接访问 /sdcard/DCIM 之类的路径。不过,应用保留对任何适用方法(例如 Context.getExternalFilesDir())返回的软件包专用路径的完整原始访问权限。
共享文件指南
将应用数据设为可供所有人访问从安全方面来讲是一种不好的做法,这会为所有人授予访问权限,并且无法限定只让目标受众访问这些数据。这种做法会导致信息披露泄露,让代理漏洞变得混乱,并会成为针对包含敏感数据的应用(例如电子邮件客户端)的恶意软件的首选目标。在 Android 9 及更高版本中,明确禁止 targetSdkVersion>=28
的应用以这种方式共享文件。
在共享文件时,请遵循以下指南,而不是让应用数据可供所有人访问:
- 如果您的应用需要与其他应用共享文件,请使用内容提供程序。内容提供程序会以适当的粒度共享数据,并且不会出现使用所有人都可访问的 UNIX 权限会带来的诸多问题(如需了解详情,请参阅内容提供程序基础知识)。
- 如果您的应用包含确实应让所有人访问的文件(例如照片),相应文件必须是媒体文件(仅限照片、视频和音频文件)且使用
MediaStore 类存储。(如需详细了解如何添加媒体内容,请参阅访问共享存储空间中的媒体文件)。
存储运行时权限控制着通过 MediaStore 对强类型媒体集合的访问权限。如需访问弱类型文件(例如 PDF)和 MediaStore.Downloads 类,应用必须使用 ACTION_OPEN_DOCUMENT
等 intent。
如需实现 Android 10 行为,请使用 requestLegacyExternalStorage
清单属性,并遵循应用权限最佳做法。
- 对于以 Android 9(及更低版本)为目标平台的应用,清单标记的默认值为
true
。
- 对于以 Android 10 为目标平台的应用,默认值为 false。如需在以 Android 10 为目标平台的应用中暂时退出已过滤的存储空间视图,请将清单标记的值设置为
true
。
- 通过使用受限权限,安装程序可以将获准使用未沙盒化存储空间的应用加入许可名单。未加入许可名单的应用会被沙盒化。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-06-12。
[null,null,["最后更新时间 (UTC):2025-06-12。"],[],[],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."]]