自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
Android 权限
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Android 权限系统提供的控件可提高用户对应用权限的认知,还可以限制应用对敏感数据的访问。在 Android 8.0 及更低版本中,权限配置包括将应用列入许可名单。特权应用如果未列入许可名单,即使位于 priv-app
路径中,也一样会被停用。在 Android 9 及更高版本上,如果设备尝试使用未正确列入许可名单的应用,则系统将无法启动。
Android 10 引入了角色的概念,这是系统中与某些要求和特权关联的独特名称。为应用分配角色以授予其针对特定用途的权限,并使用平台配置资源配置默认角色。
这些针对潜在有害应用 (PHA) 的增强型防护措施有助于:
- 更好地了解可能有害的应用的行为。
- 加强用户对应用行为的控制。
- 让应用开发者在使用受权限保护的私人数据时更加谨慎。
软件包安装和权限
在 Android 9 及更低版本中,软件包安装和权限控制功能包含在 PackageInstaller
软件包 (//packages/apps/PackageInstaller
) 中。在 Android 10 及更高版本中,权限控制功能位于单独的软件包 PermissionController
(//packages/apps/PermissionController
) 中。图 1 显示了这两个软件包在 Android 10 中的位置。
图 1. Android 10 中的软件包安装和权限控制功能
许可名单和访问权限
在 Android 6.0 及更高版本中,应用会在运行时申请危险权限。
Android 10 增加了具备活动识别 (AR) 能力的运行时权限机制,可提示用户修改或允许危险权限。
Android 8.0 要求您在系统配置 XML 文件(位于 /etc/permissions
目录下)中明确将特权应用列入许可名单。在 Android 9 及更高版本中,特许权限必须列入许可名单,否则设备无法启动。
为了限制内部 API 的可见性并防止应用意外地访问平台库,Android 7.0 推出了针对原生库的命名空间。这将系统库与应用库分离开来,而设备制造商可以添加自己的原生库。
从 Android 10 开始,应用必须拥有签名权限并征得用户同意才能访问设备的屏幕内容,两者缺一不可。依赖于静默捕获功能(如截取屏幕截图)的特权应用应改为使用 MediaProjection 类。
Android 15 要求您:在 /etc/permissions
目录下的系统配置 XML 文件中,明确将那些由非系统应用请求或由系统应用更新最新请求的平台签名权限列入许可名单。
透明度和隐私权
Android 6.0 及更高版本会阻止 Wi-Fi 服务提供方和数据包分析器访问设备的出厂 MAC 地址。自 Android 10 起,还有其他一些限制条件会限制应用访问不可变设备标识符 (ID),除非相应应用已列入特许权限许可名单。(连接部分提供了有关设备标识符的相关讨论,因为运营商会受其影响)。
在 Android 9 及更低版本中,用户在向应用授予位置信息访问权限时做出的选择是永久性的。从 Android 10 开始,三态位置信息权限功能为用户提供了三个选项,用来控制应用如何访问设备的位置信息。无论目标 SDK 设置如何,这些权限要求都适用于 Android 10 中的应用。
从 Android 10 开始,您需要配置其他透明度和隐私权功能的权限
配置简化
Android 6.0 及更高版本中的权限配置已经过简化。
- 由
init
启动的服务的 Ambient 权能可将服务配置的所有方面的信息保存在单个 .rc
文件中。在为并非由 init
所启动的服务设置权能时,请改为使用 fs_config.c
来配置文件系统权能。
- Android 7.x 及更低版本使用设备专属的
android_filesystem_config.h
文件来指定文件系统权能和/或自定义设备制造商 AID,从而扩展了 Android ID (AID) 机制。Android 8.0 及更高版本支持采取一种新方法来扩展文件系统权能。
- Android 8.0 将 USB 命令的处理从设备专属的
init
脚本(替代 HAL 层)移至了原生 USB 守护程序。在每部搭载 Android 8.0 及更高版本的设备上,必须实现 USB HAL 接口。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-04。
[[["易于理解","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"]],["最后更新时间 (UTC):2025-03-04。"],[],[],null,["# Android permissions provide controls that increase user awareness and limit\nan app's access to sensitive data. Configuring permissions on Android 8.0 and\nlower includes allowlisting, without which privileged apps are disabled, even\nif they're in the `priv-app` path. On Android 9 and higher, a device\nthat tries to use apps that aren't properly allowlisted won't boot.\n\nAndroid 10 introduced the concept of a\n[role](https://developer.android.com/reference/android/app/role/RoleManager), a unique\nname within the system associated with\ncertain requirements and privileges. Assign roles to apps to grant them permissions for\na specific purpose, and configure default roles using platform config resources.\n\nThe increased protections against\n[Potentially\nHarmful Apps](https://developers.google.com/android/play-protect/potentially-harmful-applications) (PHAs) improve:\n\n- Transparency into potentially harmful app behavior.\n- User control over app behavior.\n- App developers' discretion when using private data, protected by permissions.\n\n### Package install and permission\n\nIn Android 9 and lower, the package install and permission control\nfunctionalities were contained in the `PackageInstaller` package\n(`//packages/apps/PackageInstaller`). In Android 10 and higher, the permission control functionality\nresides in a separate package, `PermissionController`\n(`//packages/apps/PermissionController`). [Figure 1](#package-install)\nillustrates where the two packages reside in Android 10.\n\n**Figure 1.** Package install and\npermission-control functionalities in Android 10\n\n### Allowlists and access\n\nIn Android 6.0 and higher, apps request access to dangerous permissions at\n[runtime](/docs/core/permissions/runtime_perms).\nAndroid 10 adds activity recognition (AR) runtime\npermissions, which prompt the user to modify or allow dangerous\npermissions.\n\nAndroid 8.0 required you to explicitly allowlist privileged apps in the\nsystem configuration XML files in the `/etc/permissions` directory.\nIn Android 9 and higher, privileged permissions must be\n[allowlisted](/docs/core/permissions/perms-allowlist)\nor the device can't boot.\n\nTo limit internal API visibility and prevent apps from accidentally\naccessing platform libraries, Android 7.0 introduced\n[Namespaces\nfor Native Libraries](/docs/core/permissions/namespaces_libraries). This separates system libraries from app\nlibraries, and device manufacturers can add their own native libraries.\n\nStarting in Android 10 apps must have both\nsignature permissions and user consent to [access a device's screen content](/docs/core/permissions/restricted-screen-reading). Privileged apps that rely on the silent\ncapture functionality, such as taking a screenshot, should use the\n[MediaProjection](https://developer.android.com/reference/android/media/projection/MediaProjection)\nclass instead.\n\nAndroid 15 requires you to explicitly\n[allowlist](/docs/core/permissions/signature-permission-allowlist)\nplatform signature permissions that are requested by nonsystem apps or newly requested by updates\nto system apps, in the system configuration XML files in the `/etc/permissions`\ndirectory.\n\n### Transparency and privacy\n\nIn Android 6.0 and higher, a device factory MAC address is protected from\naccess by Wi-Fi service providers and packet analyzers. Additional restrictions as\nof Android 10 limit apps from accessing the\n[immutable\ndevice identifiers (IDs)](/docs/core/permissions/immutable-device-ids) unless they're [allowlisted for privileged permissions](/docs/core/permissions/perms-allowlist). (The [**Connectivity**](/docs/core/connect) section provides a related discussion about\n[Device\nIdentifiers](/docs/core/connect/device-identifiers), as this impacts carriers.)\n\nOn Android 9 and lower, users make persistent choices when granting location\naccess to apps. Starting in Android 10, a\n[tristate\nlocation permissions](/docs/core/permissions/tristate-perms) feature gives users three options to allow app access\nto a device's location. These permission requirements are applied to apps in\nAndroid 10 regardless of target SDK.\n\nConfigure permissions for other transparency and privacy features starting\nin Android 10\n\n- The [background access location](/docs/core/permissions/background-location-access) reminder shows users when an app accesses their device location using [ACCESS_FINE_LOCATION](https://developer.android.com/reference/android/Manifest.permission#ACCESS_FINE_LOCATION) permission in the background.\n- Contacts-affinity related data, managed by the Contacts Provider component, is accessed differently: Apps can't write to or read from the [contact\n affinities](/docs/core/permissions/contacts-affinities) data in the database. This impacts [caller-related APIs](/docs/core/permissions/contacts-affinities#APIchanges).\n\n### Streamlined configurations\n\nPermissions configurations have been streamlined for Android 6.0 and\nhigher.\n\n- [Ambient\n capabilities](/docs/core/permissions/ambient) for services launched by `init` keeps all aspects of the service configuration in a single `.rc` file. When setting capabilities for services not launched by `init`, configure file system capabilities using `fs_config.c` instead.\n- Android 7.x and lower extend the Android IDs (AIDs) mechanism, using a device-specific `android_filesystem_config.h` file to specify filesystem capabilities and/or custom device-manufacturer AIDs. Android 8.0 and higher supports a [new method\n to extend filesystem capabilities](/docs/core/permissions/filesystem).\n- In Android 8.0, handling USB commands moved out of device-specific `init` scripts (a substitution for HAL layers) and into a native USB daemon. The [USB HAL](/docs/core/permissions/usb-hal) interface must be implemented on every device launching on Android 8.0 and higher."]]