How to Publish an Android App to Google Play: Complete Guide

Apps mobile · By · Published on · Updated on · 7 min read

Close-up of colorful, blurred code on a computer screen with shallow depth of field
Illustrates development and preparing an app before publishing to the Play Store. Photo: Godfrey Atima / Pexels

This step-by-step guide shows how to publish an Android app to Google Play, from preparing the project to review and release. You’ll generate the signing key, build the AAB, complete the store listing, pick test tracks, and submit a secure release.

Prerequisites and initial checklist

Before publishing, make sure the app is ready for release. Have an active developer account in the Play Console, a unique applicationId, an updated version (versionCode/versionName), and a publicly accessible privacy policy.

Review app permissions and libraries. Keep the target SDK up to date and support required architectures. If the app uses custom APIs, plan for security, authentication, and rate limits.

For apps that consume APIs, review backend protection and performance best practices. See resources like Secure APIs with OAuth2 and rate limiting and reducing REST API latency for tips on caching, distributed caches, and query optimization.

  • Active developer account
  • Final and unique applicationId
  • Incremented versionCode and defined versionName
  • Hosted, accessible privacy policy
  • Icon, screenshots, and descriptions ready
  • Dependency and permissions check completed

1) Generate and securely store the signing key (keystore)

You must sign the app for distribution. The private key identifies your app for future updates. If you lose this key, you won’t be able to publish updates for the same applicationId. Store the keystore file and passwords with secure backups.

The command below creates a keystore and alias. Adjust names, validity, and paths for your project.

keytool -genkeypair -v \
  -keystore myapp-release.keystore \
  -alias myapp_key \
  -keyalg RSA -keysize 2048 \
  -validity 36500

2) Configure signing and versioning in Gradle

Set up the release build with signing, minification, and version numbers. Do not commit the keystore to Git and use environment variables for passwords. Ensure versionCode increments with every upload (required).

Example (Groovy) for the app module build.gradle:

android {
  defaultConfig {
    applicationId "com.seu.dominio.myapp"
    versionCode 12
    versionName "1.11.0"
  }
  signingConfigs {
    release {
      storeFile file("../keystore/myapp-release.keystore")
      storePassword System.getenv("KEYSTORE_PASSWORD")
      keyAlias "myapp_key"
      keyPassword System.getenv("KEY_PASSWORD")
      v2SigningEnabled true
      v3SigningEnabled true
    }
  }
  buildTypes {
    release {
      minifyEnabled true
      shrinkResources true
      proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
      signingConfig signingConfigs.release
    }
  }
}

3) Generate the Android App Bundle (AAB) for upload

New apps on the Play Store use the AAB (Android App Bundle). It enables optimized distribution per device. Build the release bundle with Gradle. Verify the release build is signing correctly.

The resulting file is typically at app/build/outputs/bundle/release/app-release.aab.

./gradlew clean bundleRelease

4) Policies, integrity, and data security

Before upload, complete the app content forms (age ratings, target audience), the Data safety section (what data you collect/share and why), and integrity settings (Play App Signing / Integrity API).

Have a clear privacy policy that matches the app’s actual behavior. Do not declare unnecessary permissions and explain data use transparently. Keep libraries updated to reduce risk.

If the app depends on APIs, ensure strong authentication, request throttling, and backend observability. Resources like structured logs and request correlation help analyze post-release failures.

  • Complete "App content" and "Data safety"
  • Enable Play App Signing (recommended)
  • Review sensitive permissions (camera, location, etc.)
  • Update dependencies and remove obsolete libs

5) Store listing: text and media

The store page impacts conversion and compliance. Prepare assets in advance and optimize readability. Use direct language and highlight benefits clearly.

Follow the dimension and format requirements shown in the console. Use real in-app screenshots and emphasize differentiators without making unrealistic claims.

  • Title, short description, and full description
  • High-resolution icon and promotional images
  • Screenshots per device type and video if applicable
  • Category and keywords aligned with the app
  • Privacy policy and contact information

6) Testing tracks, review, and release

Use tracks to validate the app before production. Add testers, gather feedback, and fix crashes before a wide release. Always increase versionCode for each submission.

After uploading the AAB, monitor the prelaunch report and policy/security warnings. When stable, promote the build to production or do a staged rollout.

Track Typical use Who receives
Internal Quick validation by team and QA Small restricted list of testers
Closed Testing with a controlled group (closed beta) Invited users
Open Public beta to collect feedback at scale Any user who opts into testing
Production General availability All eligible users

Final checks and common troubleshooting

Confirm the listing is complete, there are no policy blockers, and the version has been promoted to the correct track. Install the app on a real device via Play to validate the signed update.

Common errors can delay release. Use console messages to fix issues quickly and establish a repeatable process. If you want to automate builds and uploads, consider a CI/CD pipeline; see CI/CD with GitHub Actions for structuring the flow, even for Android.

  • Invalid signature: wrong keystore/alias/passwords or key changed
  • Repeated versionCode: increment for every release
  • Changed applicationId: prevents updates to the existing app
  • Sensitive permissions without clear justification: review and adjust the form
  • Crashes on specific devices: check architectures and use the prelaunch report
  • Slow/unstable APIs: review caching and backend performance

Frequently asked questions

Do I need to upload an APK or an AAB to the Play Store?

For new apps, upload an Android App Bundle (AAB). Google Play uses the AAB to generate device-optimized APKs, which can reduce download size and improve installs. Build the release bundle with Gradle, verify the release is signed correctly, and upload the produced app-release.aab from your build outputs before completing the store listing.

Can I change the applicationId after publishing?

No: the applicationId uniquely identifies the app in the Play Console and on users’ devices. If you change it, Google Play treats the package as a different app, and existing users will not receive updates. Keep the original applicationId for all updates you intend to deliver to the same published app.

What happens if I lose the signing keystore?

If you lose the signing keystore or its passwords you generally cannot sign future updates with the same key, which prevents publishing updates for that applicationId. The guide advises generating the key securely, keeping restricted access, and storing backups so you can sign and upload subsequent releases without interruption.

How long does publication review take?

Review time varies based on app content, new-app checks, and any permissions or policy concerns; apps requesting sensitive permissions or new apps may take longer. The Play Console shows automated and manual checks and any policy warnings to address. Plan for a review window, monitor the console, and resolve issues flagged there for faster approval.

How do I update an already published app?

To update a published app, increment versionCode, build a new signed AAB with the same signing key, and upload it to the Play Console. Update release notes and recheck any App content or Data safety forms if your app’s behavior changed, then promote the new build to the desired track (internal, closed, open, or production).

Which media assets are required for the store listing?

Prepare an icon, screenshots for relevant device types, and descriptive text (title, short and full descriptions); promotional images and a video are optional but can help conversion. Follow the Play Console’s dimension and format requirements shown when creating the listing, and use real in-app screenshots that reflect actual functionality without making unsupported claims.

Need help publishing your Android app?

If you want assistance with signing, policy checklist, build automation, or the upload flow to Google Play, let’s discuss your project.

Talk about Android publishing

See also