A finished Android build is not a launched app. Between the two sit a stack of Play Console forms and policies, and most first-time launches lose days to them, not to code. We’ve taken our own apps through review several times, and these are the parts that matter.
A privacy policy at a URL that never changes
Every app needs a privacy policy link, whether or not it collects data. The policy has to name the developer, say what’s collected and why, and give a contact.
The part people miss is permanence. That URL lives in your store listing, and Google checks it again later. When we rebuilt our studio site, two live apps still pointed at old policy pages, so those addresses now permanently redirect to the new ones. If your policy lives on a marketing site, treat its address as an API: never break it.
The Data safety form has to match the app
The Data safety section asks what data you collect, whether it’s shared, whether it’s encrypted in transit, and whether users can delete it. Be literal. If your app sends crash reports to an analytics SDK, that’s collection. If it sends a voice note to an AI service to be transcribed, that’s sharing, even if nothing is stored.
Google compares the form against what the app actually does, including the SDKs bundled inside it. A mismatch is one of the most common rejection reasons, and it’s an easy one to avoid: list every third-party service the app talks to before you open the form.
Account deletion, in the app and on the web
If people can create an account in your app, they must be able to delete it from inside the app and from a web page you link in the listing. The web page exists for people who’ve already uninstalled the app.
Test that page signed out. On one of our launches, a signed-out visit to the deletion page went through sign-in and then landed on the home screen instead of back on the deletion page. Technically the feature worked. In practice, a reviewer would have seen a page that didn’t let them delete anything.
Give the reviewer a way in
If any part of the app is behind sign-in, the App access section asks how a reviewer can get past it. Provide working test credentials or clear instructions. “Sign in with Google” is fine as long as nothing after it depends on an invitation, a paid plan or data the reviewer won’t have.
Testing rules for new developer accounts
Personal developer accounts created since late 2023 can’t publish to production straight away. You first run a closed test with at least 12 testers who stay opted in for 14 days in a row, then apply for production access. Organization accounts are exempt.
Plan for this early. Twelve real people opted in for two weeks takes organizing, and the clock only starts once they’ve joined.
The rest of the checklist
- Content rating: a short questionnaire; answer it honestly and the rating follows.
- Target audience: say whether the app is aimed at children. If it is, stricter rules apply.
- Ads declaration: whether the app shows ads at all.
- Target API level: Google raises the minimum Android version you must target every year, for new apps and for updates. An app that sits untouched for long enough eventually can’t be updated until it’s brought up to date.
- App bundle and signing: new apps upload an Android App Bundle (
.aab), and Google holds the app signing key. Keep your upload key safe; losing it means a support request, not a quick fix. - Store listing assets: a 512×512 icon, a 1024×500 feature graphic, and at least two phone screenshots.
Then wait
Review usually takes a few days, and longer for new accounts or apps in sensitive categories. Google doesn’t promise a time. Don’t schedule a launch announcement for the day you submit.
The good news is that almost everything above is decided once. Get the privacy URL, deletion page and data safety answers right for the first release, and later updates usually go through with little friction.