Play Console SDK Requirements for Third-Party Libraries

1. The responsibility clause is the whole policy in one sentence. Play's SDK Requirements page states: "If you include an SDK in your app, you are responsible for ensuring that their third-party code and practices are compliant with Google Play Developer Program Policies and do not cause your app to violate policies." Android's own guidance removes the last excuse: "Note that you as the app developer are responsible for the SDK's data collection behavior, even if you don't use a particular function of the SDK." "The SDK did it" has never been a defense, and the dependency you never call still ships in your bundle. §https://support.google.com/googleplay/android-developer/answer/13326895

2. How Play actually knows what you ship: the dependencies file, not your privacy policy, not your declaration. "To find out which SDK your app is using, we use the dependencies file included in your app. The dependencies file lists all of the versioned libraries that the app is dependent on. Apps using the Android App Bundle provide the dependencies file by default. Apps created before August 2021 publishing with APKs include the dependencies file starting from Android Gradle Plugin 4.0." Consequence: enforcement is per SDK version, so "we pinned it for stability" is exactly the state that gets a release rejected. §https://support.google.com/googleplay/android-developer/answer/10358880

3. Three severities, three different outcomes, and only one of them has a clock. "If applicable, issues with SDK versions used by your app are detailed in Play Console at the top of the Production page, or on the Release overview page." (a) A version that may make the app non-compliant: "new app releases using that SDK version can be rejected" — and you are directed to make the usage comply with the User Data policies, switch to a version the SDK owner recommends, or remove the SDK. (b) A version the owner reports as outdated or having notable issues: a warning, strongly encouraged to follow the owner's instructions. (c) A version with critical issues: "you can still temporarily release another app version. However, you must update to a newer SDK version within 90 days of that release. After 90 days, you won't be able to release further app versions using the SDK version with critical issues." The 90 days run from that release, not from the day somebody reads the banner — which is why shipping "one more build" on a flagged version silently starts a stop-ship timer for every app in the account that shares the dependency. §https://support.google.com/googleplay/android-developer/answer/10358880

4. Data safety is the declaration surface for SDK behaviour, and it is reviewed. "All developers must declare how they collect and handle user data for the apps they publish on Google Play, and provide details about how they protect this data through security practices like encryption. This includes data collected and handled through any third-party libraries or SDKs used in their apps. You may want to refer to your SDK providers' published Data safety information for details. Check Google Play SDK Index to see if your provider has provided a link to their guidance." So an SDK that collects an identifier you never declared is not an SDK problem — it is an inaccurate Data safety section, which is a separate violation with its own enforcement. §https://support.google.com/googleplay/android-developer/answer/10787469

5. Children's apps are categorical, not risk-weighted. "Apps which include children in their target audience should not transmit the following from children or users of unknown age: Android Advertising ID (AAID), SIM Serial, Build Serial, BSSID, MAC, SSID, IMEI, IMSI." Apps that solely target children "should never transmit these identifiers", and only apps targeting children and older age groups "may only transmit these identifiers from users that they know are adults". Play adds that apps solely targeting children "must only use SDKs that have self-certified their compliance with Google Play's Families Ads Program requirements to show ads and should only use SDKs which are approved for use in child-directed services" — and the Families Self-Certified Ads SDK Program page currently states it is not accepting new applicants, so the published certified list is the actual constraint, not a wishlist you can expand by switching mediation partners. §https://support.google.com/googleplay/android-developer/answer/11043825 §https://support.google.com/googleplay/android-developer/answer/9900633

6. Consent has to reach the SDK, or it is decoration. Play requires developers to "Only share user data collected through your app with a third party when they need it", to "Be aware of how the SDKs in your app handle user data; know what permissions they use, what data they collect, and why", and to "Ensure your SDK providers implement logic that reads and adheres to the app developer-collected user preference, or ensure that a mechanism exists for the app developer to accurately initialize the SDK integrated into the app according to this user-facing consent event." A dialog that sets a flag nothing reads is the most common audit failure in this area, and it is checkable in ten minutes with one grep for the SDK's init call. §https://support.google.com/googleplay/android-developer/answer/13326895

7. Use the two Google tools as pre-flight, not as post-mortem. Google Play SDK Index "combines usage data from Google Play apps with information gathered through code detection to provide attributes and signals designed to help you decide whether to adopt, keep, or remove an SDK from your app", drawing on apps "that have at least 1,000 installs" and that share their library dependencies; Google Play SDK Console gives SDK providers crash reporting, usage statistics and a channel to push critical issues to developers through Play Console and Android Studio. Check both before adopting a version, and when a version-specific compliance question is genuinely ambiguous, Play's own advice is to contact the SDK owner rather than guess. §https://support.google.com/googleplay/android-developer/answer/12034434 §https://developer.android.com/distribute/sdk-index

8. What an auditable SDK inventory looks like. One row per dependency per app: Maven coordinate, exact resolved version, why it is there, what it collects and which Data safety category that maps to, which runtime permissions and identifiers it touches, where its initialization is gated on consent, the SDK owner's contact and advisory feed, and the date compliance was last re-checked. Then three habits: diff the resolved dependency graph in CI on every bump so an SDK cannot arrive as a transitive surprise, read the top of the Production page and the Release overview before each rollout instead of after a rejection, and treat any critical-issue banner as a calendar item with a hard internal deadline well inside Google's 90 days. That is the difference between answering "why is this library in our build" in a minute and reconstructing it from release notes months later. §https://developer.android.com/guide/practices/sdk-best-practices