Disclaimer: Policy summaries and Key Considerations are overviews only; always refer to the full policy for compliance. The full policy takes precedence in case of conflict.
Policy preview
- Location Permissions: Apps targeting Android 17 (API 37+) must use the Android location button for one-time or infrequent location requests. To use
ACCESS_FINE_LOCATION, you must submit a Play Console declaration justifying why coarse location or the location button is insufficient. -
Contacts Permission: Broad access to users' contacts is now restricted. If your app does not require broad access for its core functionality, you must use the more secure Android Contact Picker.
- AppFunctions API: Developers must ensure their AppFunctions do not deceive or manipulate AI agents, bypass security controls, or interfere with other applications.
- Manage Contacts Permission: Restricted to core app functionality when system pickers are insufficient. Apps targeting Android 18 or higher (API 38+) must submit a Play Console declaration to use this permission. All other apps must use narrowly scoped platform intents.
-
Local Network Permission: Restricted to core app functionality when device pickers are insufficient. Apps targeting Android 17 or higher (API 37+) must submit a Play Console declaration to use this permission.
To view the current "Permissions and APIs that Access Sensitive Information" article, visit this page.
To promote user trust, Google Play mandates that requesting permissions and APIs that access sensitive user data must be necessary for the app's core functionalities as promoted in your Google Play listing and limited to user consented purposes. Sensitive data must never be misused, under-disclosed, or accessed unnecessarily. Request permissions and sensitive APIs incrementally, explaining each level. Use data only as consented to, and obtain new consent for other purposes. Please review the full policy to ensure compliance.
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
To safeguard user privacy, Google Play defines restricted permissions, subjecting them to additional requirements and mandates apps to responsibly use these permissions and not to manipulate users into granting access. Respect user choices when they decline permission requests and provide alternatives. Be aware that certain restricted permissions might have further additional requirements. Please review the full policy to ensure compliance.
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.
| Do | Don't |
| If a user denies a restricted permission, your app must honor that decision without manipulation. | Don't use permissions to violate Google Play's Malware policy, including Elevated Privilege Abuse. |
| Offer a different way to perform a function if a user denies a permission, such as allowing manual data entry. | Don't manipulate or deceive users. Never pressure or trick users into granting permissions. |
| Follow the User Data policy, because all data accessed through these permissions is sensitive. | Don't deny a user a reasonable alternative if they decline a Restricted Permission; ensure the app remains functional. |
Request dangerous permissions (for example, READ_CALENDAR) with a runtime request and a clear explanation. |
Don't request without justification. Only request a restricted permission for a compelling, critical feature that has no alternative. |
Direct users to the system settings page for approval of special permissions (for example, SYSTEM_ALERT_WINDOW). |
System pickers and alternatives like Sharesheet are designed to support a privacy-oriented path for developers. Photos, Videos, Contacts, and other personal and sensitive data gated by restricted permissions should be treated with privacy best practices. Your app should only request and carry the sensitive permissions below if minimum scope alternatives are not sufficient to provide your core functionality. For more information, see our Help Center.
-
All user Contacts are personal and sensitive data subject to the User Data policy.
-
Apps that target Android 17 or higher (API level 37+) may only request the
READ_CONTACTSpermission if the Android Contact Picker is not sufficient for your app to provide core functionality. Apps that still request theREAD_CONTACTSpermission must submit a Play Console declaration to demonstrate access needs for Contacts and why Contact Picker would not suffice.
-
Apps may not disclose or publish non-public Contacts data unless authorized by the individual data subjects (the contacts themselves).
-
All user Contacts are personal and sensitive data subject to the User Data policy.
-
Apps may only request the
MANAGE_CONTACTSpermission if the narrowly scoped platform intents that allow contact adding and editing, (such as ACTION_INSERT, ACTION_EDIT) are not sufficient for your app's core functionality. All apps that still require theMANAGE_CONTACTSpermission must submit a Play Console declaration to demonstrate access needs for contact management (editing, writing and management) as well as why the available alternatives would not suffice.
-
Photo and Video Permissions
-
All user Photos are personal and sensitive data subject to the User Data policy.
-
Apps that target Android 13 or higher (API level 33+) may only request the
READ_MEDIA_IMAGESandREAD_MEDIA_VIDEOpermissions if system pickers (like the Android Photo Picker) are not sufficient for your app to provide core functionality. Apps that still request theREAD_MEDIA_IMAGESandREAD_MEDIA_VIDEOpermissions must submit a Play Console declaration to demonstrate access needs for Photos and why Android Photo Picker (or alternatives) would not suffice.
-
Local Network Permission
-
Local network data accessed via the
ACCESS_LOCAL_NETWORKpermission is subject to the User Data policy. -
Apps that target Android 17 or higher (API level 37+) may only request the
ACCESS_LOCAL_NETWORKpermission if it is necessary for their core functionality and if device pickers (like NsdManager) are not sufficient to provide core functionality. -
Apps that request the
ACCESS_LOCAL_NETWORKpermission must submit a Play Console declaration to justify access and explain why the device pickers are not sufficient to provide the required core functionality associated with local network data. Device pickers are designed to provide narrow access to specific device information for supported use cases.
-
All Files Access Permission
-
All user Files and directory attributes are personal and sensitive data subject to the User Data policy. Apps may not request access to device storage on behalf of any third-party for any purpose unrelated to core functionality.
-
Apps that target Android 11 or higher (API level 30+) may only request the
MANAGE_EXTERNAL_STORAGEpermission if platform intents (like Storage Access Framework), are not sufficient for your app to provide core functionality. Apps that still request theMANAGE_EXTERNAL_STORAGEpermission must submit a Play Console declaration to demonstrate access needs for device storage and why alternatives would not suffice. Those granted permission must clearly prompt users to enable "All files access" for their app under "Special app access" settings. Read the Help Article.
SMS and Call Log Permissions
Google Play imposes strict restrictions on accessing highly sensitive SMS and Call Log data. Your app must be the designated default handler for SMS, Phone, or Assistant to request these permissions. Usage is limited only to documented core app functionality that is absolutely essential for your app's primary purpose. This data must never be used for advertising or any other unapproved purpose. Please review the full policy to ensure compliance.
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.
| Do | Don't |
| Submit a declaration form in your Play Console. | Don't request SMS/Call Log permissions without a core need justification. |
| Clearly document the core functionality requiring access to your users. | Don't use this data for advertising or other purposes. |
| Use policy-compliant alternatives like the SMS Retriever API where possible. | Don't store or share unnecessary SMS or Call Log data. |
| Stop accessing data immediately upon losing default handler status. | Don't attempt to derive this data using alternative methods. |
| Review the permitted uses and exceptions of the SMS and Call log permissions. |
Location Permissions
Device location is regarded as personal and sensitive user data subject to the User Data policy. Google Play restricts access to location permissions to protect user privacy. The following restrictions apply:
- Do not access data protected by location permissions (for example,
ACCESS_FINE_LOCATION,ACCESS_COARSE_LOCATION,ACCESS_BACKGROUND_LOCATION) once it is no longer needed to deliver your app's core functionality. - Never request location permissions solely for advertising or analytics. Apps that extend permitted usage of this data for advertising must be in compliance with our Ads policy.
- Background location may only be used to provide features beneficial to the user and relevant to the core functionality of the app.
- For guidance on the mandatory declaration and review process for Background location, please refer to the Understanding location in the background permissions article.
Minimum scope requirements for device location APIs
- Always request the minimum scope needed for your app's core functionality. Use coarse if your use case does not require precise location, and foreground if your use case does not require background. Users must reasonably expect the level of location access requested. We may reject apps that request background location without strong justification.
- For apps targeting Android SDK version 37 (Android 17) or higher:
- If your app only needs precise location (
ACCESS_FINE_LOCATION) for one-time, user-initiated actions, you must use the Android location button. Declare theonlyForLocationButtonflag in your app's manifest.
- If your app only needs precise location (
- You may only request
ACCESS_FINE_LOCATIONif neither the Android location button (for apps targeting Android 17 or higher) nor theACCESS_COARSE_LOCATIONpermission (applicable across all Android versions) can support your feature.
Foreground Service Location Access
Your app may access location using a foreground service (when the app only has foreground access for example, "while in use") permission only if
- the access continues a direct, user-initiated action in the app, and
- the service stops immediately after completing that user action.
Apps designed specifically for children must comply with the Google Play Families Policies.
For more information on the policy requirements, review the Location Button and Foreground Location Guide and Understanding Background Location Permissions.
| Do | Don't |
| Comply with the Google Play Families Policies for apps targeting children. | Don't use device location solely for advertising or analytics purposes. |
| Review important permission requirements before you submit your app for publishing. | Don't access data after it's no longer needed. |
| Complete the Console declaration for background location and foreground location. | Don't request device location for apps directed at children. |
|
Use the Android location button for one-time actions on Android 17+. |
Don't sell device location data. |
|
Use coarse location when sufficient and precise location is not needed. |
Package (App) Visibility Permission
QUERY_ALL_PACKAGES
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 higher, broad visibility to installed apps via the
QUERY_ALL_PACKAGES- You may not use
QUERY_ALL_PACKAGES
- You may not use
- Use of alternative methods to approximate the broad visibility level associated with
QUERY_ALL_PACKAGES - Please see this Help Center article for allowable use cases for the
QUERY_ALL_PACKAGES
- For apps targeting API level 30 or higher, broad visibility to installed apps via the
- 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.
| Do | Don't |
Submit a declaration form in your Play Console for QUERY_ALL_PACKAGES and any other high-risk permissions. |
Don't request |
| For your app review, clearly document why your app needs app visibility whether broad or more targeted. | Don't gain broad app visibility via methods not explicitly allowed by policy. |
| Access only the minimum data needed. | Don't provide false information about your app's core functionality or data needs. |
| Review the Permitted uses of the QUERY_ALL_PACKAGES permission for allowable use cases. | Don't collect or use unnecessary data from installed app data. |
Accessibility API
Google Play restricts the use of the AccessibilityAPI and isAccessibilityTool flag, enforces feature bans, and sets clear disclosure rules based on app designation. The Accessibility API is prohibited from being used to bypass Android security and privacy controls, record remote call audio, or power autonomous decision-making agents. Apps with a core functionality intended to directly support people with disabilities are eligible to set isAccessibilityTool=true, publicly designating themselves as accessibility tools. All other apps using the API must explicitly document usage on their Google Play listing, provide prominent in-app disclosures, and secure affirmative user consent. Developers must use more narrowly scoped APIs whenever possible.
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 platform security controls, 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
- an app that autonomously initiates, plans, and executes actions or decisions
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.
Apps must use more narrowly scoped APIs and permissions in lieu of the Accessibility API when possible to achieve the desired functionality.
Please refer to the AccessibilityService API help center article for more information regarding prohibited use cases and guidance for using IsAccessibilityTool.
| Do | Don't |
Declare isAccessibilityTool=true accurately if your app’s main goal is disability support in your service’s metadata file. |
Don't misuse the isAccessibilityTool flag. Don’t use it if your app is not a disability support tool. |
| Provide a clear Play Console declaration and demo video if using AccessibilityService API. | Don't change user settings without permission, bypass privacy controls, or record remote call audio. |
| Implement clear in-app disclosure and obtain user consent if not a designated accessibility tool. | Don't use the API to autonomously initiate, plan, and execute actions or decisions. |
| Complete an accessibility declaration when you submit a declaration form in your Play Console if you have not declared your app to be an accessibility tool but use the AccessibilityService API. | Don't deceive or mislead users. The API cannot be used to change or leverage the UI in a deceptive way. |
| Limit data collection and use strictly to the disclosed and declared purposes. | Don't collect unnecessary data. The data collected must be strictly limited to the disclosed purposes. |
| Use more narrowly scoped APIs and permissions in lieu of the Accessibility API when possible to achieve the desired functionality. | Don't bypass disclosure requirements. Disclosures cannot be a substitute for privacy policy or other app descriptions. |
Request Install Packages Permission
REQUEST_INSTALL_PACKAGES permission allows apps to request the installation of other app packages. This permission is restricted to the app's core functionality, specifically when the primary purpose directly involves sending, receiving, or enabling user-initiated installation of app packages. Using this permission to update your app, change its functionality or bundle other APKs for silent or unauthorized installation (except enterprise management) is prohibited. All installations must be a direct, active choice by the user. Apps targeting Android 8+ must hold this permission in order to use Intent.ACTION_INSTALL_PACKAGE. Please review the full policy to ensure compliance.
The REQUEST_INSTALL_PACKAGES
- 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.
TheREQUEST_INSTALL_PACKAGES
| Do | Don't |
| Clearly and prominently document the core functionality requiring this permission in your app’s Google Play description and when you submit a declaration form in your Play Console. | Don't request this permission for a functionality that is not directly related to the primary purpose of your app. This includes Peer-to-Peer (P2P) sharing. P2P must be the primary purpose of the app in order to qualify as a permitted use. |
|
Adhere strictly to the permitted functionalities including web browsing/search, file sharing / transfer / management, enterprise device management, backup/restore, device migration / phone transfer, companion app to sync phone to wearable or IoT device. |
Don't request this permission when the required task can be done with a less intrusive method. |
| Ensure your app prevents background or unintended installations. All app package installations must be explicitly initiated by the user. |
Don't change how your app uses this permission without first revising your Play Console declaration with updated and accurate information. Deceptive and undeclared uses of this permission are prohibited. |
Body Sensor Permissions
To safeguard user privacy, Google Play mandates that access to highly sensitive body sensor data (such as heart rate, SpO2, and skin temperature) is subject to our User Data policy and Health apps policy.
Starting with Android 16, apps must migrate from the general android.permission.BODY_SENSORS permission to new, granular health permissions. For example, you will use android.permission.health.READ_HEART_RATE to access heart rate data. This change affects all apps that target Android 16 or higher across all form factors, including Wear OS. For a complete list of changes, see Behavior changes: Apps targeting Android 16 or higher page. We review all requests for body sensor permissions—both legacy and new—to ensure your app's use case directly benefits the user and strictly complies with our policies.
Access to data from sensors that measure physical parameters of the body (such as heart rate, SpO₂, and skin temperature) is considered personal and sensitive user data. Apps requesting access are subject to the requirements outlined in the User Data policy and the Health apps policy. This applies to requests for android.permission.BODY_SENSORS and android.permission.BODY_SENSORS_BACKGROUND permissions across all form factors including phones, tablets, and Wear OS devices.
Starting in Android 16, the broad BODY_SENSORS permission is being transitioned in favor of granular, more privacy preserving android.permissions.health.* permissions for specific data types (for example, android.permission.health.READ_HEART_RATE, android.permission.health.READ_OXYGEN_SATURATION, android.permission.health.READ_SKIN_TEMPERATURE).
Apps targeting Android 16 or higher must use these specific permissions for APIs previously requiring BODY_SENSORS. See the Behavior changes: Apps targeting Android 16 or higher page for full details.
All requests for body sensor permissions (both legacy and new granular permissions) will be reviewed so that the intended use of this personal and sensitive data aligns with approved use cases that directly benefit the user. Approved use cases primarily involve features for fitness and wellness tracking (for example, real-time workout monitoring), medical or condition monitoring, health research (with appropriate approvals), or enhancing wearable companion app features.
For comprehensive policy guidance, including prohibited uses, acceptable use cases, and detailed requirements, see the Android Health Permissions: Guidance & FAQs.
| Do | Don't |
Use specific granular health permissions like android.permission.health.READ_HEART_RATE instead of the broad |
Don’t declare |
| Ensure your app has a core, user-benefiting feature (for example, for fitness tracking or health monitoring) that strictly requires the data. | Don't access data without a clear, direct user benefit. |
| Comply with the User Data and Health apps policies. | Don't request or use body sensor data for unapproved purposes, such as for general advertising, analytics, or profiling users based on inferred health conditions. |
| Request only the minimum permissions necessary and the specific data required for your app's intended purpose. | Don't ignore or attempt to bypass the fundamental User Data and Health apps policies. |
| Consult the Android Health Permissions: Guidance & FAQs for a full list of use cases and requirements. |
Health Connect by Android Permissions
Access to Health Connect data is restricted to apps with approved health, fitness, medical care, or health research core use cases. You must strictly limit data access to the minimum scope necessary for these approved functions and obtain explicit user consent before sharing any health data with third parties. Transparency is key, so provide clear disclosures and a comprehensive privacy policy explaining data collection, use, management, and deletion. Secure user data against unauthorized access and comply with all applicable laws and regulations (for example, HIPAA, GDPR). Please review the full policy to ensure compliance.
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
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 include: fitness and wellness, rewards, fitness coaching, corporate wellness, medical care, health research, and games. Applications granted access to these use cases may not extend its use to undisclosed or non-permitted purposes.
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:
- Applications or services allowing users to directly journal, report, monitor, and/or analyze their physical activity, sleep, mental well-being, nutrition, health measurements, physical descriptions, health records, and/or other health or fitness-related descriptions and measurements.
- Applications or services allowing users to store their physical activity, sleep, mental well-being, nutrition, health measurements, physical descriptions, health records, and/or other health or fitness-related descriptions and measurements on their device, and share their data with other on-device apps that satisfy these use cases.
- Applications or services enabling users to manage chronic conditions, medical treatments, or care support.
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, harm to individuals, 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.
- Do not use Health Connect to connect to applications, services, or features that solely target children.
- 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.
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. For example, if you are a covered entity or business associate subject to the Health Insurance Portability and Accountability Act (HIPAA), you must comply with applicable requirements for your access and use of information from Health Connect. If you are a developer subject to the General Data Protection Regulation (GDPR) for EU users, you must similarly comply with your obligations under the GDPR. These laws and regulations may require you to execute additional agreements prior to sharing data (for example, a Business Associate Agreement or Data Processing Agreement) with the relevant entities involved in your processing activities. It is also the responsibility of app developers to determine whether their activities require such agreements. Developers must provide evidence of such agreement or compliance to Google upon request.
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.
Limited Use
When using Health Connect, data access and use must adhere to specific limitations:
- Data use should be limited to providing or improving the appropriate use case or features visible in the application's user interface.
- User data may only be transferred to third parties with explicit user consent: for security purposes (for example, to investigate abuse), to comply with applicable laws or regulations, or as part of mergers/acquisitions.
- Human access to user data is restricted unless explicit user consent is obtained, for security purposes, to comply with laws, or when aggregated for internal operations as per 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 user data with any product or service that may qualify as a medical device, unless the medical device app complies with all applicable regulations, including obtaining necessary clearances or approvals from relevant regulatory bodies (for example, U.S. FDA) for its intended use of Health Connect data, and the user has provided explicit consent for such use.
- Transferring, selling, or using user data for any purpose or in any manner involving Protected Health Information (as defined by HIPAA) unless user-initiated and in compliance with HIPAA regulations.
Minimum Scope
You must only request access to the permissions that are necessary to implementing 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 Control
Health Connect handles health and fitness data that includes personal and sensitive information. Developers must provide clear and accessible disclosures about their data practices through a comprehensive privacy policy. These disclosures must include:
- Accurate representation of the identity of the application or service requesting access to user data.
- Clear and accurate information explaining the types of data being accessed, requested, and/or collected. The data must be related to a user-facing feature or recommendation offered in your app.
- Explanation for 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 disclose all use cases to users.
- User help documentation explaining how users can manage and delete their data from the app, and what happens to the data when an account is deactivated and/or deleted.
- Information regarding handling all personal and sensitive user data securely, including transmitting it using modern cryptography (for example, over HTTPS).
For more information on requirements for apps connecting to Health Connect, please see this Help Center article.
| Do | Don't |
| Your app must comply with the Health apps policy if it qualifies as a health app or has health-related features and accesses health data including Health Connect data. | Don't use Health Connect in high-risk apps (for example, aviation, control of life-critical systems such as pacemakers) or in apps that solely target children. |
| See Android Health Permissions: Guidance and FAQs to request access to Health Connect data types and other FAQs. | Don't sell or transfer user data for advertising, creditworthiness, or data brokers. |
| Submit a declaration form in your Play Console and provide a clear and detailed justification explaining how your app will use the data to benefit the user. | Don't use with medical devices without required regulatory compliance/clearances. |
| Request only the minimum necessary data types. | Don't access Health Connect data for secondary or unapproved purposes. |
| Securely handle user data (for example, use modern cryptography). | Don't request data permissions beyond your app's core functionality. |
VPN Service
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.
| Do | Don't |
| Document use of the VpnService clearly in the Google Play listing. | Don't use VpnService for purposes other than core VPN or specified exceptions. |
| Must encrypt the data from the device to the VPN tunnel end point. | Don't collect personal and sensitive user data without prominent disclosure and consent. |
| Ensure your app's core functionality aligns with VPN use or permitted exceptions. | Don't 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). |
| Provide prominent in-app disclosure and obtain explicit consent for any sensitive data collection. |
Exact Alarm Permission
USE_EXACT_ALARM permission on Android 13+ is a highly restricted permission used only for apps whose core, user-facing functionality genuinely requires precise timing, like dedicated alarm, timer, or calendar applications with event notifications. If your app does not have this specific core need, consider using SCHEDULE_EXACT_ALARM
A new permission, USE_EXACT_ALARM
USE_EXACT_ALARM
Acceptable use cases for using the Exact Alarm Permission
Your app must use the USE_EXACT_ALARM
- 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
| Do | Don't |
Request the auto granted version of the permission, USE_EXACT_ALARM, only if your app's core functionality is of alarm or calendar. |
Don't use this permission for non-critical features that do not directly contribute to the app's main purpose. |
Use SCHEDULE_EXACT_ALARM instead if the above criteria is not met. |
|
| Complete Play Console declaration to indicate app functionality. | |
| Review the new permission to use exact alarms for more information on exact alarm functionality. |
Full-Screen Intent Permission
USE_FULL_SCREEN_INTENT
For apps targeting Android 14 (API target level 34) and above, USE_FULL_SCREEN_INTENTUSE_FULL_SCREEN_INTENT
- 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
Learn more about the USE_FULL_SCREEN_INTENT
| Do | Don't |
| Request user consent for the permission and provide a clear explanation for the request if not auto-granted. | Don't use this permission for non-core or low-priority features. |
|
Limit use to necessary high-priority notifications/alerts. |
Don't use this permission to interfere with devices or other apps. |
| Submit a declaration form in your Play Console to establish pre-grant eligibility for the full-screen intent permission if targeting Android 14+ | Don't use this permission for disruptive ads or disruptive notifications. |
Learn more about the |
Age Signals API and User Data
To help protect user’s data, you may only use data provided by the Age Signals API to provide age-appropriate experiences in the app receiving this data. These guidelines ensure that you use the API strictly to meet compliance requirements and not for commercial gain or tracking.
This policy defines the conditions for your use of the Age Signals API, which provides access to personal and sensitive user age and parental consent data.
You may only use the data accessed via the Age Signals API for the sole purpose of complying with applicable legal and regulatory obligations such as providing age appropriate experiences within your app.
You are strictly prohibited from using this data for the following purposes, including but not limited to:
- Advertising, marketing, or personalization purposes, including the serving of targeted ads
- Data analytics, user profiling, or business intelligence
- Selling, sharing, or transferring the data to any third party for any reason, except as strictly required by law
| Do | Don't |
| Limit data use to regulatory compliance use cases. | Don't use this data to perform marketing or targeting advertising. |
| Check for parental consent requirements. | Don’t use this data to perform analytics or user profiling. |
| Ensure the user’s experiences match the user’s age. | Don’t share this data with a third-party for any reason except as required by law. |
AppFunctions API
The AppFunctions API enables developers to expose functions or tools within their apps that AI agents can call to perform tasks on behalf of the user - like searching for information or taking actions. As with any app feature you release, you are responsible for ensuring it operates safely, securely, and complies with all Google Play Developer Program policies, including those regarding Privacy, Deception, and Device Abuse policies and Malware.
To maintain safety for users and AI agents, your AppFunctions must comply with the following additional requirements:
- Accurate Representation: AppFunctions must accurately represent their capabilities in all app metadata, including function names, parameters, and descriptions. Any mismatch between described functionality and actual runtime behavior is strictly prohibited.
- Prohibition of Deceptive Practices: AppFunctions must not attempt to deceive or manipulate AI agents, including using prompts or instructions designed to deceive or influence an AI agent into performing adverse actions or behaviors. Additionally, AppFunctions must not:
- return hidden system instructions or prompts dynamically in runtime responses. All instructions intended for AI agents must be declared upfront during function registration or metadata ingestion.
- reference or attempt to dictate execution rules for other applications' AppFunctions.
- Security and Abuse: AppFunctions must not attempt to circumvent the AI agent’s security, privacy, safety, or abuse protections. AppFunctions must not manipulate AI agents into revealing sensitive system instructions or sensitive user data. In accordance with the Device and Network Abuse policy, apps must not interfere with other apps. This prohibition includes AppFunctions that interfere with the ability for an AI agent to select or call other apps, tools, or services.
- AppFunction Inputs and Data Handling: When defining AppFunctions schemas, parameters, or required inputs, developers must restrict the scope to only what is required for the tool to operate, as described in the tools description. Additionally, you must comply with all requirements defined within our User Data policy. Be sure to account for the collection, use, and sharing of user data that occurs through your AppFunctions when populating your mandatory data safety section.
To learn more about best practices when building AppFunctions please review the Android developer documentation.
Help us improve this policy article by taking a 2-minute survey.