Permissions and APIs that Access Sensitive Information

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 they affirmatively agree to the additional uses.

Restricted Permissions

Full Policy

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 Permissions

Full Policy

SMS and Call Log Permissions are regarded as personal and sensitive user data subject to the Personal and Sensitive Information policy, and the following restrictions:

Restricted Permission	Requirement
Call Log permission group (for example, READ_CALL_LOG, WRITE_CALL_LOG, PROCESS_OUTGOING_CALLS)	It must be actively registered as the default Phone or Assistant handler on the device.
SMS permission group (for example, READ_SMS, SEND_SMS, WRITE_SMS, RECEIVE_SMS, RECEIVE_WAP_PUSH, RECEIVE_MMS)	It must be actively registered as the default SMS or Assistant handler on the device.

 

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 Center 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 Permissions

Full Policy

Device 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 may not access data protected by location permissions (for example, ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_BACKGROUND_LOCATION) after it is no longer necessary to deliver current features or services in your app.
• You should never request location permissions from users for the sole purpose of advertising or analytics. Apps that extend permitted usage of this data for serving advertising must be in compliance with our Ads Policy.
• Apps should request the minimum scope necessary (for example, coarse instead of fine, and foreground instead of background) to provide the current feature or service requiring location and users should reasonably expect that the feature or service needs the level of location requested. For example, we may reject apps that request or access background location without compelling justification.
• Background location may only be used to provide features beneficial to the user and relevant to the core functionality of the app.

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:

• has been initiated as a continuation of an in-app user-initiated action, and
• is terminated immediately after the intended use case of the user-initiated action is completed by the application.

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 Permission

Full Policy

Files 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:

• Apps should only request access to device storage which is critical for the app to function, and may not request access to device storage on behalf of any third-party for any purpose that is unrelated to critical user-facing app functionality.
• Android devices running R or later, will require the MANAGE_EXTERNAL_STORAGE permission in order to manage access in shared storage. All apps that target R and request broad access to shared storage (“All files access”) must successfully pass an appropriate access review prior to publishing. Apps allowed to use this permission must clearly prompt users to enable “All files access” for their app under “Special app access” settings. For more information on the R requirements, please see this help article.

Photo and Video Permissions

Full Policy

Photos and videos on a user’s device are regarded as personal and sensitive user data subject to Google Play's User Data policy. Apps may only access photos and videos for purposes directly related to app functionality, and may not request access on behalf of any third-party for any purpose unrelated to user-facing app functionality. For a more privacy preserving experience, we encourage the use of a system picker such as the photo picker.

Apps requiring broad access to photos and video files located in shared storage on devices must successfully pass an appropriate access review and demonstrate a core use case that requires persistent or frequent photo/video access of files located in shared storage. Apps that have a one-time or infrequent need to access these files are requested to use a system picker, such as the Android photo picker.

Broad access to photos and videos are also subject to the following requirements:

• Apps that target Android 13 (API level 33) or later, require the READ_MEDIA_IMAGES permission or READ_MEDIA_VIDEO permission in order to obtain broad access to photos or video files located in shared storage on the device. All apps that target Android 13 and above and request the READ_MEDIA_IMAGES or READ_MEDIA_VIDEO permissions must successfully pass an appropriate access review before publishing.
  • Apps that request access to the READ_MEDIA_VIDEO or READ_MEDIA_IMAGES permission must successfully demonstrate a core use case that requires persistent or frequent need of photo/video access located in shared storage.

If your app does not require or qualify for broad access to the READ_MEDIA_VIDEO or READ_MEDIA_IMAGES permissions, you must remove it from your app’s manifest in order to successfully meet the policy review requirements.

In accordance with the Restricted Permissions policy, you must make a reasonable effort to accommodate users who do not grant broad access to media files on their device. This includes gracefully facilitating an accommodative app experience where users can still enjoy the feature or core functionality of your app.

Apps that have a legitimate access case for photos or videos, but do not qualify for the READ_MEDIA_IMAGES nor READ_MEDIA_VIDEO permission may use a system picker such as the photo picker. For additional information, please see this Help Center article.

Package (App) Visibility Permission

Full Policy

The 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:

• Broad app visibility: Broad visibility is the capability of an app to have extensive (or “broad”) visibility of the installed apps (“packages”) on a device.
  • For apps targeting API level 30 or later, broad visibility to installed apps via the QUERY_ALL_PACKAGES permission is restricted to specific use cases where awareness of and/or interoperability with any and all apps on the device are required for the app to function.
    • You may not use QUERY_ALL_PACKAGES if your app can operate with a more targeted scoped package visibility declaration(for example, querying and interacting with specific packages instead of requesting broad visibility).
  • Use of alternative methods to approximate the broad visibility level associated with QUERY_ALL_PACKAGES permission are also restricted to user-facing core app functionality and interoperability with any apps discovered via this method.
  • Please see this Help Center article for allowable use cases for the QUERY_ALL_PACKAGES permission.
• Limited app visibility: Limited visibility is when an app minimizes access to data by querying for specific apps using more targeted (instead of “broad”) methods(for example, querying for specific apps that satisfy your app’s manifest declaration). You may use this method to query for apps in cases where your app has policy compliant interoperability, or management of these apps.
• Visibility to the inventory of installed apps on a device must be directly related to the core purpose or core functionality that users access within your app.

App inventory data queried from Play-distributed apps may never be sold nor shared for analytics or ads monetization purposes.

Accessibility API

Full Policy

The Accessibility API cannot be used to:

• Change user settings without their permission or prevent the ability for users to disable or uninstall any app or service unless authorized by a parent or guardian through a parental control app or by authorized administrators through enterprise management software; 
• Work around Android built-in privacy controls and notifications; or
• Change or leverage the user interface in a way that is deceptive or otherwise violates Google Play Developer Policies. 

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 IsAccessibilityTool

Apps 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 center 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 Permission

Full Policy

The 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:

• Sending or receiving app packages; and
• Enabling user-initiated installation of app packages.

Permitted functionalities include:

• Web browsing or search
• Communication services that support attachments
• File sharing, transfer, or management
• Enterprise device management
• Backup and restore
• Device Migration/Phone Transfer
• Companion app to sync phone to wearable or IoT device (for example, smart watch or smart TV)

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.

Body Sensor Permissions

Full Policy

Health Connect by Android Permissions

Full Policy

Health Connect is an Android platform that allows health and fitness apps to store and share the same on-device data, within a unified ecosystem. It also offers a single place for users to control which apps can read and write health and fitness data, including health records. Health Records may include medical history, diagnoses, treatments, medications, lab results, and other clinical data, obtained from healthcare providers or institutions, or through supported third-party health platforms.

Health Connect supports reading and writing a variety of data types, from steps to body temperature, to health record data.

Data accessed through Health Connect Permissions is regarded as personal and sensitive user data subject to the User Data policy. If your app qualifies as a health app or has health-related features and accesses health data including Health Connect data, it must also comply with the Health apps policy.

Please see this Android developer guide on how to get started with Health Connect. To request access to Health Connect data types and other FAQs, see Android Health Permissions: Guidance & FAQs.

Apps distributed through Google Play must meet the following policy requirements in order to read and/or write data to Health Connect.

Appropriate Access to and Use of Health Connect

Limited Use

Minimum Scope

Transparent and Accurate Notice and Control

VPN Service

Full Policy

The 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:

• Parental control and enterprise management apps
• App usage tracking
• Device security apps (for example, anti-virus, mobile device management, firewall)
• Network related tools (for example, remote access)
• Web browsing apps
• Carrier apps that require the use of VPN functionality to provide telephony or connectivity services

The VpnService cannot be used to:

• Collect personal and sensitive user data without prominent disclosure and consent.
• Redirect or manipulate user traffic from other apps on a device for monetization purposes (for example, redirecting ads traffic through a country different than that of the user).

Apps that use the VpnService must:

• Document use of the VpnService in the Google Play listing, and
• Must encrypt the data from the device to VPN tunnel end point, and
• Abide by all Developer Program Policies including the Ad Fraud, Permissions, and Malware policies.

Exact Alarm Permission

Full Policy

A 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:

• The app is an alarm or timer app.
• The app is a calendar app that shows event notifications.

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 Permission

Full Policy

For 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:

• setting an alarm
• receiving phone or video calls

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 unauthorized 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 Center.