Android app submission checklist

Last updated: July 2026

Start here: what makes Play different from the App Store

Every 'app submission checklist' you'll find is a static list someone wrote once and never opened again. The catch is that most of it doesn't apply to your build, so you end up guessing which of 130 items are relevant. This tool takes the opposite route: it reads your actual .apk or .aab — the manifest, the permissions, the target SDK — and hands back the ~12 checks that fail on that binary. The checklist below fills in everything a binary can't tell you: the store listing, the policy forms, the rollout.

Two things about Google Play trip up people coming from iOS. First, you publish an Android App Bundle (.aab), not an APK — mandatory for new apps since August 2021. Second, there's no annual fee: a single $25 registration covers you for life, versus Apple's $99 every year. Almost everything else is a different shape of the same idea — signing, privacy disclosures, a review queue.

Store listing assets: the exact dimensions

Get these wrong and the Console won't let you publish. These are the specs Google enforces, not rounded-off approximations:

Google Play graphic asset, screenshot & video specifications

Metadata and character limits

The text fields have hard caps, and a few carry policy risk if you abuse them:

Target API level: the deadline that actually blocks uploads

This is the single most common reason an upload is rejected outright — and it's on a clock. Google requires new apps and updates to target a recent Android API level, and it raises the bar by one level roughly every 31 August.

Right now the floor is API 35 (Android 15), enforced since 31 August 2025. If your targetSdkVersion sits below it, the Play Console blocks the upload before a human ever looks.

Our .apk analyzer reads targetSdk, the debuggable flag and the cleartext-traffic setting straight from the manifest — so it tells you whether this specific build clears the current floor, instead of leaving you to read the Console error after a failed upload.

Google Play target API level requirements

The Data safety form: map it from your manifest

Since 20 July 2022, every app must complete the Data safety section, and a form that contradicts your app's real behaviour is a rejection — or worse, an enforcement action after launch.

The trap: the form asks about data collection, but your manifest declares permissions, and the two don't line up one-to-one. Here's how the permissions our analyzer already extracts usually translate into a declaration:

Google Play Data safety section guidance

The testing-track ladder (and the 20-tester rule)

You don't submit straight to production. Play has four tracks and you climb them in order:

1. Internal testing — up to 100 testers by email, live within minutes. Use it to catch crashes before anyone else sees the build.
2. Closed testing — a named tester list or Google Group. New personal accounts must run this with at least 20 testers opted in, continuously, for 14 days before production access unlocks.
3. Open testing — a public beta anyone can join from a link. Optional, but it surfaces device-specific breakage the analyzer can't see: OEM skins, old GPUs, tiny screens.
4. Production — the full rollout. Start with a staged 10–20% and watch Android vitals (crash rate, ANR) before pushing to 100%.

One more gate: the account itself costs a one-time $25 to register, and if you signed up as an individual after late 2023, that 20-testers-for-14-days closed test is mandatory before Google even shows you the production track.

Google Play testing requirements for new personal accounts

Rejection reasons → fixes, at a glance

Here after a rejection? Find your reason and jump to the fix:

Got wording you don't recognise? Decode it against 17 real rejection patterns

Free interactive checklist — it remembers what you've ticked

Work through the store-listing and policy side here. It saves to your browser, so you can close the tab and come back to where you left off, and the print button gives you a clean PDF to hand a client. The deep, build-specific findings (privacy manifest, ATS, permission purpose strings, the full 58-item guideline audit) come from uploading your file.

That's the store side covered. For the parts that live inside the binary — and their fixes — the auditor reads them off your file directly.

Doing iOS too?

Most of what's above is Android-specific. The App Store has its own list: App Tracking Transparency, the privacy nutrition labels, a launch storyboard, and Apple's $99/year program.

Shipping to both stores? Run through the App Store submission checklist

FAQ

Sources

• Google Play — target API level requirements
• Google Play — graphic assets, screenshots & video specs
• Google Play — Data safety section guidance
• Google Play — testing requirements for new personal accounts
• Google Play — content ratings (IARC)
• Android Developers — about Android App Bundles
• Google Play — register for a developer account ($25 fee)