SDK requirements

App developers often rely on third-party code (for example, an SDK) to integrate key functionality and services for their apps. When including an SDK in your app, you want to make sure that you can keep your users safe and your app secure from any vulnerabilities. In this section, we demonstrate how some of our existing privacy and security requirements apply in the SDK context and are designed to help developers safely and securely integrate SDKs into their apps.

If you include an SDK in your app, you are responsible for ensuring that their third-party code and practices do not cause your app to violate Google Play Developer Programme Policies. It is important to be aware of how the SDKs in your app handle user data and to ensure that you know what permissions they use, what data they collect, and why. Remember, an SDK's collection and handling of user data must align with your app's policy-compliant use of said data.

To help ensure that your use of an SDK does not violate policy requirements, read and understand the following policies in their entirety and note some of their existing requirements pertaining to SDKs below:

User data policy

You must be transparent in how you handle user data (for example, information collected from or about a user, including device information). That means disclosing the access, collection, use, handling and sharing of user data from your app, and limiting the use of the data to the policy-compliant purposes disclosed.

If you include third-party code (for example, an SDK) in your app, you must ensure that the third-party code used in your app, and that third party’s practices with respect to user data from your app, are compliant with Google Play Developer Programme Policies, which include use and disclosure requirements. For example, you must ensure that your SDK providers do not sell personal and sensitive user data from your app. This requirement applies regardless of whether user data is transferred after being sent to a server, or by embedding third-party code in your app.

Personal and sensitive user data Limit the access, collection, use and sharing of personal and sensitive user data acquired through the app to app and service functionality and policy-conforming purposes reasonably expected by the user: Apps that extend usage of personal and sensitive user data for serving advertising must comply with Google Play’s ads policy. Handle all personal and sensitive user data securely, including transmitting it using modern cryptography (for example, over HTTPS). Use a runtime permissions request whenever available, prior to accessing data gated by Android permissions Sale of personal and sensitive user data Do not sell personal and sensitive user data. 'Sale' means the exchange or transfer of personal and sensitive user data to a third party for monetary consideration. User-initiated transfer of personal and sensitive user data (for example, when the user is using a feature of the app to transfer a file to a third party, or when the user chooses to use a dedicated purpose research study app), is not regarded as sale. Prominent disclosure and consent requirements In cases where your app’s access, collection, use or sharing of personal and sensitive user data may not be within the reasonable expectation of the user of the product or feature in question, you must meet the prominent disclosure and consent requirements of the user data policy. If your app integrates third-party code (for example, an SDK) that is designed to collect personal and sensitive user data by default, you must, within two weeks of receipt of a request from Google Play (or, if Google Play’s request provides for a longer time period, within that time period), provide sufficient evidence demonstrating that your app meets the prominent disclosure and consent requirements of this policy, including with regard to the data access, collection, use or sharing via the third-party code. Remember to ensure that your use of third-party code (for example, an SDK) does not cause your app to violate the user data policy. Refer to this Help Centre article for more information on the prominent disclosure and consent requirement. Examples of SDK-caused violations An app with an SDK that collects personal and sensitive user data and doesn’t treat this data as subject to this user data policy, access, data handling (including disallowed sale), and prominent disclosure and consent requirements. An app integrates an SDK that collects personal and sensitive user data by default in violation of this policy’s requirements regarding user consent and prominent disclosure. An app with an SDK that claims to collect personal and sensitive user data only to provide anti-fraud and anti-abuse functionality for the app, but the SDK also shares the data that it collects with third parties for advertising or analytics. An app includes an SDK that transmits users’ installed packages information without meeting the prominent disclosure guidelines and/or privacy policy guidelines. Also refer to the mobile unwanted software policy. Additional requirements for personal and sensitive data access The table below describes requirements for specific activities. Activity Requirement Your app collects or links persistent device identifiers (for example, IMEI, IMSI, SIM Serial No., etc.) Persistent device identifiers may not be linked to other personal and sensitive user data or resettable device identifiers except for the purposes of: Telephony linked to a SIM identity (for example, Wi-Fi calling linked to an operator account) and Enterprise device management apps using device owner mode. These uses must be prominently disclosed to users as specified in the user data policy. Please consult this resource for alternative unique identifiers. Please read the ads policy for additional guidelines for Android advertising ID. Your app targets children Your app may only include SDKs that have self-certified for use in child-directed services. See Families Self-Certified Ads SDK Programme for full policy language and requirements.   Examples of SDK-caused violations An app using an SDK which links Android ID and location An app with an SDK which connects AAID to persistent device identifiers for any advertising purpose or analytics purpose. An app using an SDK that connects AAID and email address for analytics purposes. Data safety section All developers must complete a clear and accurate Data safety section for every app detailing collection, use and sharing of user data. This includes data collected and handled through any third-party libraries or SDKs used in their apps. The developer is responsible for the accuracy of the label and keeping this information up to date. Where relevant, the section must be consistent with the disclosures made in the app’s privacy policy. Please refer to this Help Centre article for additional information on completing the Data safety section. See the full user data policy.

Permissions and APIs that access sensitive information policy

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. See the full Permissions and APIs that access sensitive information policy. Examples of SDK-caused violations Your app includes an SDK which requests location in the background for an unallowed or undisclosed purpose. Your app includes an SDK which transmits IMEI derived from the read_phone_state Android permission without user consent.

Malware policy

Our malware policy is simple: the Android ecosystem including the Google Play Store and user devices should be free from malicious behaviours (for example, malware). Through this fundamental principle we strive to provide a safe Android ecosystem for our users and their Android devices. Malware is any code that could put a user, a user's data or a device at risk. Malware includes, but is not limited to, potentially harmful applications (PHAs), binaries or framework modifications, consisting of categories such as trojans, phishing and spyware apps, and we are continuously updating and adding new categories. See the full malware policy. Examples of SDK-caused violations An app that violates the Android permissions model, or steals credentials (such as OAuth tokens) from other apps. Apps that abuse features to prevent them from being uninstalled or stopped. An app that disables SELinux. Your app includes an SDK that violates the Android permissions model by gaining elevated privileges through the access of device data for an undisclosed purpose Your app includes an SDK with code that tricks users into subscribing to or purchasing content via their mobile phone bill. Privilege escalation apps that root devices without user permission are classified as rooting apps.

Mobile unwanted software policy

Transparent behaviour and clear disclosures All code should deliver on promises made to the user. Apps should provide all communicated functionality. Apps should not confuse users. Example violations: Ad fraud Social engineering Protect user data Be clear and transparent about the access, use, collection and sharing of personal and sensitive user data. Uses of user data must adhere to all relevant user data policies, where applicable, and take all precautions to protect the data. Example violations: Data collection (cf spyware) Restricted permissions abuse See the full mobile unwanted software policy

Device and network abuse policy

We don’t allow apps that interfere with, disrupt, damage or access in an unauthorised manner the user’s device, other devices or computers, servers, networks, application programming interfaces (APIs) or services, including but not limited to other apps on the device, any Google service or an authorised operator network. Apps or third-party code (for example, SDKs) with interpreted languages (JavaScript, Python, Lua, etc.) loaded at run time (for example, not packaged with the app) must not allow potential violations of Google Play policies. We don’t allow code that introduces or exploits security vulnerabilities. Review the App security improvement programme to find out about the most recent security issues flagged to developers. See the full device and network abuse policy. Examples of SDK-caused violations Apps that facilitate proxy services to third parties may only do so in apps where that is the primary, user-facing core purpose of the app. Your app includes an SDK that downloads executable code, such as dex files or native code, from a source other than Google Play. Your app includes an SDK containing a webview with added JavaScript Interface that loads untrusted web content (for example, http:// URL) or unverified URLs obtained from untrusted sources (for example, URLs obtained with untrusted intents) Your app includes an SDK that contains code used for updating its own APK Your app includes an SDK that exposes users to a security vulnerability by downloading files over an insecure connection. Your app is using an SDK which contains code to download or install applications from unknown sources outside Google Play.

Deceptive behaviour policy

We don't allow apps that attempt to deceive users or enable dishonest behaviour, including but not limited to apps which are determined to be functionally impossible. Apps must provide an accurate disclosure, description and images/video of their functionality in all parts of the metadata. Apps must not attempt to mimic functionality or warnings from the operating system or other apps. Any changes to device settings must be made with the user's knowledge and consent and be reversible by the user. See the full Deceptive behaviour policy. Behaviour transparency Your app’s functionality should be reasonably clear to users; don’t include any hidden, dormant or undocumented features within your app. Techniques to evade app reviews are not allowed. Apps may be required to provide additional details to ensure user safety, system integrity and policy compliance. Example of an SDK-caused violation Your app includes an SDK that uses techniques to evade app reviews.

What Google Play developer policies are commonly associated with SDK-caused violations?

To help you ensure that any third-party code that your app is using complies with Google Play’s Developer Programme Policies, please refer to the following policies in their entirety:

• User data policy 
• Permissions and APIs that access sensitive information 
• Device and network abuse policy 
• Malware 
• Mobile unwanted software 
• Families Self-Certified Ads SDK Programme
• Ads policy 
• Deceptive behaviour
• Google Play Developer Programme Policies 

While these policies are more commonly at issue, it is important to remember that bad SDK code could cause your app to violate a different policy not referenced above. Remember to review and stay up to date with all policies in their entirety, as it is your responsibility as an app developer to ensure that your SDKs handle your app data in a policy-compliant manner.

To find out more, please visit our Help Centre.