# Skill: Clear all four Google Play checks to publish an Android app without rejection

> Equips an AI coding/design agent to audit an Android app against Google Play's four mandatory gates — target API level, Data Safety form, banned content policy, and closed testing requirement — and fix every gap before submission.

Source: sodigi·learn — publish/trebovaniya-google-play · https://sodigi.io/learn/publish/trebovaniya-google-play

## When to use
- Preparing an Android app for first submission to Google Play.
- A build was rejected or blocked and the reason involves API level, data declarations, content policy, or testing.
- Performing a pre-submission audit of an existing app before a major update.
- A developer is using a brand-new personal Google Play developer account.

## Core rules
- Google Play is four sequential checks; failing any one of them blocks the submission entirely.
- The target API level (targetSdkVersion) must match Google's current minimum — this bar rises every year, usually in late summer; always check the official Play Console help for the current number before building.
- Data Safety covers ALL data collection inside the app, including data collected by third-party SDKs (analytics, ads, crash reporters) — the developer is responsible for declaring it all.
- Lying in the Data Safety form is not a minor oversight — Google cross-checks form answers against actual app behavior; a mismatch causes rejection on first review and a potential ban on re-review.
- Banned content (child safety, deception, non-consensual deepfakes, excessive permissions on sensitive data) results in removal without negotiation and possible account closure.
- New personal developer accounts must complete a closed test with real human testers for approximately two weeks continuously before production access is granted; organization accounts are exempt.
- Testers must keep the app installed and active — rejoining after dropping out does not count toward the continuous requirement.
- A working privacy policy URL is required alongside the Data Safety form.

## Procedure
1. Open the official Play Console requirements page and note the current target API level and the cutoff deadline for new apps/updates.
2. Bump targetSdkVersion in build.gradle to the current required level. Run the full app and check that nothing broke after the bump (permissions behavior and APIs often change with each API level).
3. List every library and SDK in the project. For each one, check its documentation to determine what user data it collects or shares.
4. Fill out the Data Safety form in Play Console honestly: declare every data type collected (by your code AND by third-party SDKs), state the purpose, mark whether it is shared with third parties, confirm encryption in transit, and specify whether users can request deletion.
5. Prepare and publish a privacy policy page at a stable, public, no-login URL. Paste the URL into the Data Safety form.
6. Re-read the Google Play Developer Program Policies on banned content. Confirm the app's topic, generated content handling, and permission requests are all within policy.
7. If the developer account is a new personal account: create a closed testing track in Play Console, recruit testers (check current minimum count in Play Console help), and run the test for the required consecutive number of days. Do not let testers drop out mid-period.
8. After closed testing completes, apply for production access. Check the official Play Console help once more for any last-minute deadline or number changes, then submit.

## Ready-to-use prompt
```
Audit my Android app for Google Play submission. Work through all four checks and flag every gap:

1. Target API level: what is the current minimum targetSdkVersion Google requires for new apps and updates as of today? Check the official Play Console help. Confirm my current value in build.gradle and tell me if it needs bumping. After bumping, list any API or permission changes in the new level I should test.

2. Data Safety form: list every third-party SDK and library in this project. For each one, identify what user data it collects or shares. Then produce a complete Data Safety declaration covering my own code and all SDKs. Flag any field I may have left blank or understated.

3. Banned content: scan the app's features, generated content handling, and permission requests against the current Google Play Developer Program Policies. Report any content or permission that falls in a restricted category.

4. Testing requirement: is this a new personal developer account? If so, outline the current closed-testing requirement (number of testers, number of consecutive days) from the official Play Console help, and create a plan to meet it before the target release date.

For each finding, tell me the exact fix and where in the code or console to apply it.
```

## Pitfalls
- Using the target API level from an old blog post or tutorial — the number changes every year; always check the official Play Console help before building.
- Declaring "no data collected" while an ad or analytics SDK is running — Google cross-checks this; the mismatch triggers rejection and can lead to a ban.
- Forgetting that third-party SDK data collection is the developer's responsibility — "I didn't write that SDK" is not an accepted defense.
- Assuming a corporate account and a personal account have the same testing requirements — personal accounts require a closed test; organizations do not.
- Counting testers who dropped out and rejoined — the closed test period must be continuous; a tester who drops counts as a reset for that seat.
- Treating the banned content policy as a one-time read — rules update; re-read the Developer Program Policy before every major submission, not just the first.
- Trusting numbers from any source other than the current Play Console help — API levels, tester counts, and deadlines go stale fast.