Google Play SDK requirements policy: fixes and checks

An SDK-caused rejection is still your app’s rejection to resolve. Google holds you responsible for third-party code, its permissions, and what its providers do with data collected through your app.

What to check

Inventory the exact SDK versions in the release artifact, including transitive dependencies. For each one, document initialization, permissions, collected data, recipients, and purpose. Compare that behavior with consent screens, the privacy policy, and Data safety answers.

Don’t assume a vendor’s anti-fraud label covers advertising or analytics. Review the actual destinations and permitted uses. Persistent identifiers, advertising IDs, child-directed services, and unexpected collection have additional restrictions.

How to address the rejection

Update, reconfigure, or remove the offending dependency. Verify that collection stops before consent where required and that removed permissions no longer appear in the merged manifest. Test cold starts and background behavior as well as the visible feature.

Google may request evidence of prominent disclosure and consent for SDK collection. Meet the deadline in that request; the policy specifies two weeks unless Google grants longer.

Use the underlying User Data, permissions, malware, and device abuse rules to check the fix. A vendor assurance doesn’t replace verification of your release build.