Publish an Android app on Google Play.

The developer account is verified and the app is created with its default language, its type (app or game) and its free or paid status. An app published as free cannot become paid later; it can still offer in-app purchases.

Verify: Play Console → Dashboard: no required setup task is pending.

Evidence: Screenshot of the app dashboard.

Play Console Help — Create and set up your app ↗ · reviewed 2026-10-23

A paid app or in-app purchases require a payments (merchant) profile linked to the developer account, with tax and banking information.

Verify: Play Console → Setup → Payments profile: active and complete.

Evidence: Screenshot of the payments profile.

Play Console Help — Payments policy ↗ · reviewed 2026-10-23

Releases are managed as Android App Bundles. Only apps created before August 2021 can still add APKs for their updates.

Verify: The uploaded file is an .aab built in release configuration.

Evidence: File name and version code.

Android Developers — About Android App Bundles ↗ · reviewed 2026-10-23

For a first release, set up Play App Signing: Google keeps the app signing key, you sign uploads with an upload key. Store that key and its password outside the repository, backed up, and know how to request a reset if it is lost.

Verify: Play Console → Test and release → App integrity: Play App Signing active; the upload key sits in a secrets vault, not in Git.

Evidence: Screenshot of the App integrity page and the backup location.

Common failure: Keystore committed to a public repository, or lost with the developer’s laptop.

Play Console Help — Use Play App Signing ↗ · reviewed 2026-10-23

As of 23 October 2026, Google’s page states that from 31 August 2026 new apps and updates must target Android 16 (API 36) or higher (Wear OS and Android Automotive: API 35; Android TV and Android XR: API 34), with an extension to 1 November 2026 available on request. Existing apps must target at least API 35 to stay available to new users on newer devices. This requirement changes every year: recheck the page before every upload.

Verify: targetSdk in build.gradle compared with Google’s page on the day of upload; test the behaviour changes of that Android version.

Evidence: targetSdk value of the uploaded build.

Common failure: Play Console refuses the update: target API level too old.

Android Developers — Meet Google Play’s target API level requirement ↗ · reviewed 2026-10-23

If the app or a library contains native code, it must ship 64-bit architectures and meet the other native-code requirements Google publishes. Check the page before uploading.

Verify: Inspect the AAB (APK Analyzer in Android Studio): every 32-bit ABI has its 64-bit counterpart.

Evidence: List of ABIs present in the bundle.

Android Developers — Support 64-bit architectures ↗ · reviewed 2026-10-23

versionCode higher than the previous release, non-debuggable build, production services, no logging of sensitive data. If you minify with R8, upload the mapping file for readable crash reports.

Verify: Install the release from the internal testing track and check the server it calls and that no debug menu is present.

Evidence: versionCode, versionName and mapping file presence.

The internal testing track (up to 100 chosen testers) installs exactly what Play will distribute, signed by Google: the most faithful test before production.

Verify: Install from the internal testing link on a device with no development build, then repeat the critical flows.

Evidence: Version code installed from the internal track.

Play Console Help — Set up an open, closed or internal test ↗ · reviewed 2026-10-23

Personal accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in continuously for at least 14 days before applying for production access. Testers who opt out before 14 days do not count. The application asks about the test, the app and its readiness; review usually takes seven days or less.

Verify: Play Console → Dashboard: the closed test counter shows at least 12 testers and 14 consecutive days.

Evidence: Screenshot of the counter and a summary of tester feedback.

Common failure: Testers recruited without real engagement: Google asks for more testing.

Play Console Help — App testing requirements for new personal developer accounts ↗ · reviewed 2026-10-23

Google automatically tests the release on real devices and reports crashes, display, accessibility and security issues. Read it before every rollout.

Verify: Play Console → Pre-launch report: no unexplained crash.

Evidence: Screenshot of the report for this version code.

Play Console Help — Use a pre-launch report ↗ · reviewed 2026-10-23

Android runs on very different devices. Test at least one low-end device, the oldest supported Android version, and a large screen if the app is available there.

Verify: Critical flows on each selected device.

Evidence: List of devices, Android versions and results.

Install, first launch, sign-up or sign-in, main task, purchase and restore if any, system back navigation and screen rotation.

Verify: Uninstall, reinstall from Play (testing track) and repeat each flow with a new account.

Evidence: Dated list of the flows tested.

Google Play’s minimum functionality rules target apps that crash, do not work or provide no value. Remove empty screens, placeholder text and buttons that do nothing.

Verify: Go through every screen of the release build looking for placeholder content and actions that do nothing.

Evidence: List of screens checked.

Google Play — Developer Program Policy center ↗ · reviewed 2026-10-23

The name, short description and full description describe what the app actually does, within the character limits Play Console shows, without keyword stuffing or unkept promises.

Verify: Every feature mentioned exists in the submitted release.

Evidence: Listing text reviewed.

Google Play — Developer Program Policy center ↗ · reviewed 2026-10-23

Icon 512 × 512 px as 32-bit PNG (1 MB max), feature graphic 1024 × 500 px, at least two screenshots (between 320 and 3840 px, long side at most twice the short side) to publish the listing. Google recommends at least four screenshots of at least 1080 px.

Verify: Play Console accepts each file without warning; each screenshot shows a real screen of the app.

Evidence: Folder of listing graphics.

Play Console Help — Add preview assets to showcase your app ↗ · reviewed 2026-10-23

Appropriate category and tags, a monitored contact email, a website if you have one.

Verify: Send a message to the displayed contact email: it arrives.

Evidence: Screenshot of the listing contact details.

Play Console Help — Choose a category and tags ↗ · reviewed 2026-10-23

The privacy policy is linked on the Play listing, and inside the app when it accesses sensitive data or permissions. It describes the data handled, its use and its sharing.

Verify: The URL opens on a phone, without an account, and matches the data actually handled.

Evidence: Policy URL and a screenshot of where it appears in the app.

Play Console Help — User Data policy ↗ · reviewed 2026-10-23

Every published app (closed, open or production tracks) completes the Data safety form, reviewed by Google then shown on the listing. It also covers third-party SDKs and every distributed version.

Verify: Compare each answer with the SDK inventory and the app’s network calls.

Evidence: SDK inventory and a screenshot of the form.

Common failure: Declaring “no data shared” while an ad SDK is present: rejection or removal.

Play Console Help — Provide information for Google Play’s Data safety section ↗ · reviewed 2026-10-23

If the app lets people create an account, it must offer an in-app path to delete the account and its data, and a web link where deletion can be requested, declared in the Data safety form. Associated data is deleted, except retention you are obliged to keep and explain.

Verify: Delete a test account from the app, then request deletion through the web link: both complete.

Evidence: In-app path, web link URL and proof of deletion on the server.

Play Console Help — App account deletion requirements ↗ · reviewed 2026-10-23

Every app needs an IARC rating; an “Unrated” app may be removed. Update the questionnaire when the content changes.

Verify: Play Console → App content: rating assigned.

Evidence: Rating certificate received by email.

Play Console Help — Content ratings ↗ · reviewed 2026-10-23

Declare the target age group. If it includes children, the Families policies apply.

Verify: Play Console → App content → Target audience: completed.

Evidence: Screenshot of the declaration.

Play Console Help — Manage target audience and app content settings ↗ · reviewed 2026-10-23

For an app targeting children: accurate answers in Target audience, Data safety and IARC, ad and data SDKs that comply with the Families policies, limited collection.

Verify: Review each SDK against the Families policies.

Evidence: SDK inventory with their status.

Play Console Help — Google Play Families policies ↗ · reviewed 2026-10-23

Declare whether the app contains ads, including those shown by third-party SDKs.

Verify: Compare the declaration with the SDK inventory.

Evidence: Screenshot of the declaration.

Play Console Help — Prepare your app for review ↗ · reviewed 2026-10-23

If part of the app requires sign-in, provide everything needed to access it (up to five instruction sets) and flag special mechanisms: one-time codes, multi-factor authentication. Never use a real customer account.

Verify: Using only these instructions, an outsider reaches every restricted feature.

Evidence: Date of the last test of the provided credentials.

Common failure: Expired test account: review fails on app access.

Play Console Help — Prepare your app for review ↗ · reviewed 2026-10-23

Declare only the permissions the app needs, request runtime permissions when the feature uses them, and keep the app usable if declined.

Verify: Compare the merged manifest (libraries included) with the actual features; decline each permission during a test.

Evidence: List of merged-manifest permissions with their use.

Android Developers — Permissions on Android ↗ · reviewed 2026-10-23

Background location, SMS and call log, all-files access, accessibility services, the list of installed apps… are subject to their own rules and declarations in Play Console. Their use must match an allowed core feature.

Verify: For each sensitive permission, the Play Console declaration is completed with a video or description of the feature.

Evidence: Declarations submitted.

Common failure: Background location requested without a feature requiring it: rejection.

Play Console Help — Permissions and APIs that access sensitive information ↗ · reviewed 2026-10-23

An app with user-generated content provides terms of use, moderation, content reporting and user blocking.

Verify: With two accounts, post, report and block: each action works.

Evidence: Screenshots of the actions and the moderation procedure.

Play Console Help — User-generated content policy ↗ · reviewed 2026-10-23

Health, finance, lending, gambling, government apps: Google Play requires declarations and sometimes supporting documents (licence, partnership). Check those that apply to your app in the policy center.

Verify: Play Console → App content: every applicable declaration is completed.

Evidence: Declarations and documents submitted.

Play Console Help — Health content and services ↗ · reviewed 2026-10-23

In-app purchases of digital goods and services go through Google Play’s billing system, unless an exception in the Payments policy or an alternative billing program available in your country applies. Check what applies to your distribution countries.

Verify: List each digital product and its payment method, with the rule that allows it.

Evidence: That list.

Play Console Help — Payments policy ↗ · reviewed 2026-10-23

Products are created and active in Play Console. Each purchase is verified on your server before access is granted, then acknowledged: a purchase not acknowledged within three days is refunded automatically and the entitlement revoked.

Verify: Purchase with a licence tester account: access is granted by the server and the purchase shows as acknowledged in Play Console.

Evidence: Server verification log and a screenshot of the order.

Common failure: Purchases refunded automatically after three days for lack of acknowledgement.

Android Developers — Integrate the Google Play Billing Library ↗ · reviewed 2026-10-23

Clear price, period and content before purchase, subscription management reachable, and planned behaviour on payment failure, cancellation or plan change.

Verify: With a licence tester account: subscribe, accelerated renewal, cancel, then check access.

Evidence: Result of each test step.

Android Developers — Google Play’s billing system ↗ · reviewed 2026-10-23

Internal testing (up to 100 testers), closed testing (chosen testers), open testing (joinable from the listing), production (all users in the chosen countries). Submitted changes go through Google’s review before publication.

Verify: The target track is written down, with the reason and the person who triggers the rollout.

Evidence: Track and version written in the project.

Play Console Help — Prepare and roll out a release ↗ · reviewed 2026-10-23

For an update, choose a rollout percentage and increase it while the indicators stay healthy; you can halt the rollout if a problem appears. Staged rollout is not available for a first release.

Verify: The initial percentage and the criterion for increasing it (crash rate, reviews) are written down.

Evidence: Chosen percentage and criterion.

Play Console Help — Release app updates with staged rollouts ↗ · reviewed 2026-10-23

Some countries impose their own requirements. Check them for each selected country.

Verify: Country list compared with the country-requirements page.

Evidence: List of selected countries.

Play Console Help — Requirements for distributing apps in specific countries/regions ↗ · reviewed 2026-10-23

Localized release notes explain what changes for the user.

Verify: Each listing language has its note.

Evidence: Notes text.

Play Console Help — Prepare and roll out a release ↗ · reviewed 2026-10-23

The release’s error summary is clear, changes are sent for review, and no policy rejection or warning is waiting for a response in Play Console. A ready release does not guarantee approval: the decision belongs to Google.

Verify: Publishing overview: changes reviewed and approved; Policy status and inbox: no open issue.

Evidence: Screenshot of the publishing overview.

Common failure: Resubmitting the same release after a rejection without addressing the cited policy.

Play Console Help — Publish your app ↗ · reviewed 2026-10-23

A rejection cites a policy. You can fix and resubmit, or appeal. Decide in advance who watches the Play Console inbox and within what delay.

Verify: The responsible person and the delay are written down.

Evidence: Procedure written in the project.

Play Console Help — Enforcement process ↗ · reviewed 2026-10-23

Android vitals measures crash rate, ANRs (app not responding) and other technical signals. High values hurt the app’s visibility; watch them after every rollout.

Verify: Play Console → Android vitals checked daily during the first week.

Evidence: Screenshot of the indicators after rollout.

Play Console Help — Monitor technical quality with Android vitals ↗ · reviewed 2026-10-23

Reviews often report a bug before your tools do, and the inbox carries policy messages.

Verify: Someone is responsible for answering reviews.

Evidence: Name of the responsible person.

Play Console Help ↗ · reviewed 2026-10-23