Permissions and APIs that Access Sensitive Information

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.

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.

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.

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.

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. 

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.

Data accessed through Health Connect Permissions is regarded as personal and sensitive user data subject to the User Data policy, and the following additional requirements:

Requests to access data through Health Connect must be clear and understandable. Health 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 you may only request access to permissions when your application or service meets one of the approved use cases.

Approved use cases for access to Health Connect Permissions are:

• Applications or services with one or more features to benefit users' health and fitness via a user interface allowing users to directly journal, report, monitor, and/or analyze their physical activity, sleep, mental well-being, nutrition, health measurements, physical descriptions, and/or other health or fitness-related descriptions and measurements.
• Applications or services with one or more features to benefit users' health and fitness via a user interface allowing users to store their physical activity, sleep, mental well-being, nutrition, health measurements, physical descriptions, and/or other health or fitness-related descriptions and measurements on their phone and/or wearable, and share their data with other on-device apps that satisfy these use cases.

Health Connect is a general purpose data storage and sharing platform that allows users to aggregate health and fitness data from various sources on their Android device and share it with third parties at their election. The data may originate from various sources as determined by the users. Developers must assess whether Health Connect is appropriate for their intended use and to investigate and vet the source and quality of any data from Health Connect in connection with any purpose, and, in particular, for research, health, or medical uses.

• Apps conducting health-related human subject research using data obtained through Health Connect must obtain consent from participants or, in the case of minors, their parent or guardian. Such consent must include the (a) nature, purpose, and duration of the research; (b) procedures, risks, and benefits to the participant; (c) information about confidentiality and handling of data (including any sharing with third parties); (d) a point of contact for participant questions; and (e) the withdrawal process. Apps conducting health-related human subject research using data obtained through Health Connect must receive approval from an independent board whose aim is 1) to protect the rights, safety, and well-being of participants and 2) with the authority to scrutinize, modify, and approve human subjects research. Proof of such approval must be provided upon request.
• It is also your responsibility for ensuring 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 labeling 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.

Upon using Health Connect for an appropriate use, your use of the data accessed through Health Connect must also comply with the below requirements. These requirements apply to the raw data obtained from Health Connect, and data aggregated, de-identified, or derived from the raw data.

• Limit your use of Health Connect data to providing or improving your appropriate use case or features that are visible and prominent in the requesting application's user interface.
• Only transfer user data to third parties:
  • To provide or improve your appropriate use case or features that are clear from the requesting application's user interface and only with the user’s consent;
  • If necessary for security purposes (for example, investigating abuse);
  • To comply with applicable laws and/or regulations; or,
  • As part of a merger, acquisition or sale of assets of the developer after obtaining explicit prior consent from the user.
• Do not allow humans to read user data, unless:
  • The user's explicit consent to read specific data is obtained;
  • It’s necessary for security purposes (for example, investigating abuse);
  • To comply with applicable laws; or,
  • The data (including derivations) is aggregated and used for internal operations in accordance with applicable privacy and other jurisdictional legal requirements.

All other transfers, uses, or sale of Health Connect data is prohibited, including:

• Transferring or selling user data to third parties like advertising platforms, data brokers, or any information resellers.
• Transferring, selling, or using user data for serving ads, including personalized or interest-based advertising.
• Transferring, selling, or using user data to determine credit-worthiness or for lending purposes.
• Transferring, selling, or using the user data with any product or service that may qualify as a medical device pursuant to Section 201(h) of the Federal Food Drug & Cosmetic Act if the user data will be used by the medical device to perform its regulated function.
• Transferring, selling, or using user data for any purpose or in any manner involving Protected Health Information (as defined by HIPAA) unless you receive prior written approval to such use from Google.

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:

• Do not use Health Connect in developing, or for incorporation into, applications, environments or activities where the use or failure of Health Connect could reasonably be expected to lead to death, personal injury, or environmental or property damage (such as the creation or operation of nuclear facilities, air traffic control, life support systems, or weaponry).
• Do not access data obtained through Health Connect using headless apps. Apps must display a clearly identifiable icon in the app tray, device app settings, notification icons, etc.
• Do not use Health Connect with apps that sync data between incompatible devices or platforms.
• Health Connect cannot connect to applications, services or features that solely target children. Health Connect is not approved for use in primarily child-directed services.

An affirmative statement that your use of Health Connect data complies with Limited Use restrictions must be disclosed in your application or on a website belonging to your web-service or application; for example, a link on a homepage to a dedicated page or privacy policy noting: “The use of information received from Health Connect will adhere to the Health Connect Permissions policy, including the Limited Use requirements.”

You may only request access to permissions that are critical to implementing your application or service's functionality. 

This means:

• Don't request access to information that you don't need. Only request access to the permissions necessary to implement your product's features or services. If your product does not require access to specific permissions, then you must not request access to these permissions.

Health Connect handles health and fitness data, which includes personal and sensitive information. All applications and services must contain a privacy policy, which must comprehensively disclose how your application or service collects, uses, and shares user data. This includes the types of parties to which any user data is shared, how you use the data, how you store and secure the data, and what happens to the data when an account is deactivated and/or deleted.

In addition to the requirements under applicable law, you must also adhere to the following requirements:

• You must provide a disclosure of your data access, collection, use, and sharing. The disclosure:
  • Must accurately represent the identity of the application or service that seeks access to user data;
  • Must provide clear and accurate information explaining the types of data being accessed, requested, and/or collected;
  • Must explain how the data will be used and/or shared: if you request data for one reason, but the data will also be utilized for a secondary purpose, you must notify users of both use cases.
• You must provide user help documentation that explains how users can manage and delete their data from your app.

You must handle all user data securely. Take reasonable and appropriate steps to protect all applications or systems that make use of Health Connect against unauthorized or unlawful access, use, destruction, loss, alteration, or disclosure.

Recommended security practices include implementing and maintaining an Information Security Management System such as outlined in ISO/IEC 27001 and ensuring your application or web service is robust and free from common security issues as set out by the OWASP Top 10.

Depending on the API being accessed and number of user grants or users, we will require that your application or service undergo a periodic security assessment and obtain a Letter of Assessment from a designated third party if your product transfers data off the user's own device.

For more information on requirements for apps connecting to Health Connect, please see this help article.

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.

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.