Changes are coming to this article
This article will be updated with recently announced changes.
For a more privacy preserving experience for users, we’re introducing the Photo and video permissions policy to reduce the number of apps permitted to request broad photo/video permissions (READ_MEDIA_IMAGES and READ_MEDIA_VIDEO). Apps may only access photos and videos for purposes directly related to app functionality. Apps that have a one-off or infrequent need to access these files are requested to use a system picker, such as the Android photo picker. (effective from 22 January 2025)
To preview the updated 'Permissions and APIs that access sensitive information' article, visit this page.
Requests for permission and APIs that access sensitive information should make sense to users. You may only request permissions and APIs that access sensitive information that are necessary to implement current features or services in your app that are promoted in your Google Play listing. You may not use permissions or APIs that access sensitive information that give access to user or device data for undisclosed, unimplemented, or disallowed features or purposes. Personal or sensitive data accessed through permissions or APIs that access sensitive information may never be sold nor shared for a purpose facilitating sale.
Request permissions and APIs that access sensitive information to access data in context (via incremental requests), so that users understand why your app is requesting the permission. Use the data only for purposes that the user has consented to. If you later wish to use the data for other purposes, you must ask users and make sure that they affirmatively agree to the additional uses.
Restricted permissions
In addition to the above, restricted permissions are permissions that are designated as Dangerous, Special, Signature or as documented below. These permissions are subject to the following additional requirements and restrictions:
- User or device data accessed through restricted permissions is considered as personal and sensitive user data. The requirements of the user data policy apply.
- Respect users’ decisions if they decline a request for a restricted permission, and users may not be manipulated or forced into consenting to any non-critical permission. You must make a reasonable effort to accommodate users who do not grant access to sensitive permissions (for example, allowing a user to manually enter a phone number if they’ve restricted access to call logs).
- Use of permissions in violation of Google Play malware policies (including elevated privilege abuse) is expressly prohibited.
Certain restricted permissions may be subject to additional requirements as detailed below. The objective of these restrictions is to safeguard user privacy. We may make limited exceptions to the requirements below in very rare cases where apps provide a highly compelling or critical feature, and where there is no alternative method available to provide the feature. We evaluate proposed exceptions against the potential privacy or security impacts on users.
SMS and call log permissionsSMS and call log permissions are regarded as personal and sensitive user data subject to the personal and sensitive Information policy, and the following restrictions:
Apps lacking default SMS, Phone or Assistant handler capability may not declare use of the above permissions in the manifest. This includes placeholder text in the manifest. Additionally, apps must be actively registered as the default SMS, phone or Assistant handler before prompting users to accept any of the above permissions, and must immediately stop using the permission when they’re no longer the default handler. The permitted uses and exceptions are available on this Help Centre page. Apps may only use the permission (and any data derived from the permission) to provide approved core app functionality. Core functionality is defined as the main purpose of the app. This may include a set of core features, which must all be prominently documented and promoted in the app’s description. Without the core feature(s), the app is 'broken' or rendered unusable. The transfer, sharing or licensed use of this data must only be for providing core features or services within the app, and its use may not be extended for any other purpose (for example, improving other apps or services, advertising or marketing purposes). You may not use alternative methods (including other permissions, APIs or third-party sources) to derive data attributed to call log- or SMS-related permissions. |
Location permissionsDevice location is regarded as personal and sensitive user data subject to the Personal and sensitive information policy and the Background location policy, and the following requirements:
Apps are allowed to access location using foreground service (when the app only has foreground access for example, 'while in use') permission if the use:
Apps designed specifically for children must comply with the Designed for Familiespolicy. For more information on the policy requirements, please see this help article. |
All files access permissionFiles and directory attributes on a user’s device are regarded as personal and sensitive user data subject to the personal and sensitive information policy and the following requirements:
|
Package (app) visibility permissionThe inventory of installed apps queried from a device are regarded as personal and sensitive user data subject to the personal and sensitive information policy, and the following requirements: Apps that have a core purpose to launch, search or interoperate with other apps on the device, may obtain scope-appropriate visibility to other installed apps on the device as outlined below:
App inventory data queried from Play-distributed apps may never be sold nor shared for analytics or ads monetisation purposes. |
Accessibility APIThe Accessibility API cannot be used to:
The Accessibility API is not designed and cannot be requested for remote call audio recording. The use of the Accessibility API must be documented in the Google Play listing. Guidelines for IsAccessibilityToolApps with a core functionality intended to directly support people with disabilities are eligible to use the IsAccessibilityTool to appropriately publicly designate themselves as an accessibility app. Apps not eligible for IsAccessibilityTool may not use the flag and must meet prominent disclosure and consent requirements as outlined in the user data policy as the accessibility-related functionality is not obvious to the user. Please refer to the AccessibilityService API Help Centre article for more information. Apps must use more narrowly scoped APIs and permissions in lieu of the Accessibility API when possible to achieve the desired functionality. |
Request install packages permissionThe REQUEST_INSTALL_PACKAGES permission allows an application to request the installation of app packages. To use this permission, your app’s core functionality must include:
Permitted functionalities include:
Core functionality is defined as the main purpose of the app. The core functionality, as well as any core features that comprise this core functionality, must all be prominently documented and promoted in the app's description. The REQUEST_INSTALL_PACKAGES permission may not be used to perform self updates, modifications or the bundling of other APKs in the asset file unless for device management purposes. All updates or installing of packages must abide by Google Play’s device and network abuse policy and must be initiated and driven by the user. |
Health Connect by Android PermissionsAppropriate access to and use of Health ConnectHealth Connect may only be used in accordance with the applicable policies, Terms and Conditions and for approved use cases as set forth in this policy. This means that you may only request access to permissions when your application or service meets one of the approved use cases. Approved use cases include: fitness and wellness, rewards, fitness coaching, corporate wellness, medical care, health research and games. Only applications or services with one or more features designed to benefit users' health and fitness are permitted to request access to Health Connect permissions. These include:
Access to Health Connect may not be used in violation of this policy or other applicable Health Connect Terms and Conditions or policies, including for the following purposes:
It is also your responsibility to ensure compliance with any regulatory or legal requirements that may apply based on your intended use of Health Connect and any data from Health Connect. Except as explicitly noted in the labelling or information provided by Google for specific Google products or services, Google does not endorse the use of or warrant the accuracy of any data contained in Health Connect for any use or purpose and, in particular, for research, health or medical uses. Google disclaims all liability associated with use of data obtained through Health Connect. Limited useWhen using Health Connect, data access and use must adhere to specific limitations:
Minimum scopeYou must only request access to the permissions that are necessary to implement your product's features or services. Such access requests should be specific and limited to the data which is needed. Transparent and accurate notice and controlHealth Connect manages health and fitness data, including sensitive information, and requires all applications to have a comprehensive privacy policy. The privacy policy must transparently disclose how the app collects, uses and shares user data. Beyond legal requirements, developers must have the following information in the privacy policy:
For more information on requirements for apps connecting to Health Connect, please see this Help Centre article. |
VPN serviceThe VpnService is a base class for applications to extend and build their own VPN solutions. Only apps that use the VpnService and have VPN as their core functionality can create a secure device-level tunnel to a remote server. Exceptions include apps that require a remote server for core functionality, such as:
The VpnService cannot be used to:
Apps that use the VpnService must:
|
Exact alarm permissionA new permission, USE_EXACT_ALARM, will be introduced that will grant access to exact alarm functionality in apps starting with Android 13 (API target level 33). USE_EXACT_ALARM is a restricted permission and apps must only declare this permission if their core functionality supports the need for an exact alarm. Apps that request this restricted permission are subject to review, and those that do not meet the acceptable use case criteria will be disallowed from publishing on Google Play. Acceptable use cases for using the exact alarm permission Your app must use the USE_EXACT_ALARM functionality only when your app’s core, user-facing functionality requires precisely timed actions, such as:
If you have a use case for exact alarm functionality that’s not covered above, you should evaluate if using SCHEDULE_EXACT_ALARM as an alternative is an option. For more information on exact alarm functionality, please see this developer guidance. |
Full-screen intent permissionFor apps targeting Android 14 (API target level 34) and above, USE_FULL_SCREEN_INTENT is a special apps access permission. Apps will only be automatically granted to use the USE_FULL_SCREEN_INTENT permission if the core functionality of their app falls under one of the below categories that require high-priority notifications:
Apps that request this permission are subject to review, and those that do not meet the above criteria will not be automatically granted this permission. In that case, apps must request permission from the user to use USE_FULL_SCREEN_INTENT. As a reminder, any usage of the USE_FULL_SCREEN_INTENT permission must comply with all Google Play developer policies, including our mobile unwanted software, device and network abuse and ads policies. Full-screen intent notifications cannot interfere with, disrupt, damage or access the user’s device in an unauthorised manner. Additionally, apps should not interfere with other apps or the usability of the device. Learn more about the USE_FULL_SCREEN_INTENT permission in our Help Centre. |
Help us improve this policy article by taking a 2-minute survey.