自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
三态位置权限
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Android 10 中的三态位置权限可让用户更好地控制应用如何访问其设备位置信息。
在 Android 9 及更低版本中,用户在向应用授予位置信息访问权限时会做出永久性选择。他们可以拒绝或允许访问;选择“允许”后,应用将始终具有访问权限(无论是在前台还是后台运行)。Android 10 中的三态位置信息权限针对是否允许应用访问设备的位置信息为用户提供了三个选项。当应用请求权限时,系统会提示用户授予或拒绝权限级别。
用户通常会看到三个选项,如图 1 所示。不过,某些使用情形下仅需要其中两个选项,在此类情况下,仅显示这两个选项。
图 1. 三态通知屏幕
下面是提供的三个选项:
- 始终允许:即使用户并未使用应用(应用在后台运行),应用也知道设备的位置信息。此选项等同于 Android 9 及更低版本中的允许权限。
- 仅在使用该应用期间允许:(仅限在前台运行的应用)只有当应用正在运行时,设备的位置信息才会向应用显示。
- 拒绝:设备的位置信息绝不会向应用显示。此选项与 Android 9 及更低版本中的拒绝权限相同。
当应用请求权限时,系统会提示用户授予位置信息访问权限。
用户授予仅在使用该应用期间允许访问权限后,应用可以请求权限升级,以期获得始终允许访问权限。用户会看到一个请求对话框(如图 2 所示)。如果用户选择保持仅在使用时访问,则在下次使用应用且应用访问设备位置信息时,该对话框会提供保持不变且不再询问选项。
对于以 Android 10 为目标平台的应用,该对话框会在以下情况下显示:
- 授予权限至少 24 个小时之后。
- 仅在应用在后台收到位置信息时。
- 屏幕处于开启状态,而且用户没有使用其他应用。
图 2. 升级权限
如需详细了解如何请求权限,请参阅应用对设备位置信息的访问权限。如需详细了解您的应用是否以 Android 9 及更低版本为目标平台,请参阅延续用户发起的操作。
影响
三态位置权限功能会影响在后台运行时需要设备位置信息访问权限的任何应用,在 Android 10 中必不可少。
您可以更改代码,但不能更改或自定义框架中与权限相关的行为。
实现
无论应用采用哪一种目标 SDK,三态位置信息权限都将应用于 Android 10 中的应用。
如需了解如何实现应用的用例(通过升级),请参阅开发者文档中的在设计时考虑设备升级情况部分。
要了解如何针对不同的使用情形启用访问权限(例如需要请求后台位置信息访问权限的 Google 地图或 Google Play 服务等应用),请在应用对设备位置信息的访问权限页面查看这些主题。
应用内位置信息访问权限
用户可以选择将您的应用的访问权限更改为拒绝或仅在使用该应用期间允许。对于应用内位置信息访问权限以及所有第一方和第三方应用,请提供下表中指定的用户控制级别。
应用需要请求的权限类型 |
提供的用户选项 |
应用仅请求前台权限 |
仅在使用该应用时允许
拒绝
|
应用始终请求权限(前台和后台)
|
始终允许
仅在使用该应用时允许
拒绝
|
请求位置信息访问权限的所有应用 |
仅在使用该应用时允许 |
这些权限适用于所有位置信息请求。具有仅在使用该应用时允许权限的应用不得进行后台 Wi-Fi 或手机网络扫描。
在 Android 11 或更低版本中,具有仅在使用该应用时允许权限的应用不得进行后台蓝牙扫描。从 Android 12 开始,具有仅在使用该应用时允许权限的应用可以通过将 android:usesPermissionFlags
属性的值设置为 neverForLocation
,获取蓝牙扫描结果。如需了解详情,请参阅应用不推导物理位置。
操作系统升级
在将操作系统升级到 Android 10 时,应用位置权限会根据以下内容进行转换:
- 开启转换为仅在使用该应用时允许。
- 关闭仍然是关闭(拒绝)。
- 预授权的位置信息访问权限转换为仅在使用该应用时允许预授权。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[[["易于理解","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-07-27。"],[],[],null,["# Tristate location permissions in Android 10 give users more control over\nhow apps access their device locations.\n\nIn Android 9 and lower, users made persistent choices when granting location access to apps. They\ncould either **Deny** or **Allow**, the latter of which gave apps access\nall the time (foreground and background). Tristate location permissions in Android 10 give users three options for allowing an app access to a device's location.\nUsers are prompted to grant or deny the permission level when an app requests it.\n\nA user normally sees the three choices presented in Figure 1. However, there are use cases where\nonly two of these options are required, and in such cases only those two are shown.\n\n**Figure 1.** Tristate notifications screen.\n\nThese are the three options:\n\n- **Allow all the time**: the device's location is known to the app even when the app is not in use (running in the background). This is equivalent to allowing permission in Android 9 and lower.\n- **Allow only while the app is in use**: (foreground only) the device's location is only visible to the app when it's actively running.\n- **Deny**: the device's location is never visible to the app. This is the same as denying permission in Android 9 and lower.\n\nUsers are prompted to grant location access permission when apps request the\npermission.\n\nOnce a user grants **Allow only while the app is in use** access permission, an app\ncan request an incremental increase in access to **Allow all the time** . The user sees\na request dialog (shown in [Figure 2](#incremental-permissions-screens)). If the user\nselects **Keep while-in-use access** , when the app accesses device location on next\nuse, the dialog provides the option to **Keep and don't ask again**.\n\nThe dialog appears under these conditions for apps targeting Android 10:\n\n- After at least 24 hours of granting the permission.\n- Only if the app is receiving locations in the background.\n- When the screen is on, and the user is not utilizing another app.\n\n**Figure 2.** Incremental permissions.\n\nTo learn more about requesting permissions, see [App access to\ndevice location](https://developer.android.com/training/location/request-updates). For details if your app targets Android 9 and lower, see [Continuation of user-initiated action](https://developer.android.com/training/location/request-updates).\n\nImpact\n------\n\nThe tristate location permissions feature affects any app that needs device location access\nwhile running in the background, and is required in Android 10.\n\nYou may change your code but you *may not* alter or customize\npermission-related behavior in the framework.\n\nImplementation\n--------------\n\nTristate location permissions are applied to apps in Android 10\nirrespective of an app's target SDK.\n\nFor information on implementing your app's use cases (on upgrades), refer to the [Design for device upgrade scenarios](https://developer.android.com/training/location/request-updates) section in the developer documentation.\n\nTo see how to enable access for different use cases (such as requiring background location\naccess for apps like Google Maps or Google Play services), view these topics on the [App access to\ndevice location](https://developer.android.com/training/location/request-updates) page:\n\n- [Request background\n location](https://developer.android.com/training/location/request-updates)\n- [Periodic checks of\n a device's location](https://developer.android.com/training/location/request-updates)\n\n### In-app location access\n\nUsers can change your app's access permissions to either **Deny** or **Allow\nonly while using the app** if they choose. For in-app location access permission, and for all\nfirst-party and third-party apps, provide the levels of user control given in the following table.\n\n| Permission type app needs to request | User options to provide |\n|------------------------------------------------------------|--------------------------------------------------------|\n| App requests foreground permissions only | Allow only while using the app Deny |\n| App requests permission always (foreground and background) | Allow all the time Allow only while using the app Deny |\n| All apps with location access requests | Allow only while using the app |\n\nThese permissions apply to all location requests. Apps with **Allow\nonly while using the app** permissions aren't allowed background Wi-Fi or\ncell scans.\n\nOn Android 11 or lower, apps with **Allow\nonly while using the app** permissions aren't allowed background\nBluetooth scans. From Android 12, apps with\n**Allow only while using the app** permissions can gain Bluetooth\nscan results by setting the value of the\n`android:usesPermissionFlags` attribute to\n`neverForLocation`. For more details, see\n[App\ndoesn't derive physical location](https://developer.android.com/about/versions/12/features/bluetooth-permissions#not-derive-physical-location).\n\nOS upgrades\n-----------\n\nOn an OS upgrade to Android 10, app location permissions translate\naccording to the following:\n\n- **On** becomes **Allow only while in Use**.\n- **Off** remains off (**Deny**).\n- Pre-granted location access becomes the **Allow only while in use** pre-grant."]]