Preparing Your App for Google Play Submission
Preparing Your App for Google Play Submission
Shipping a Flutter app to the Google Play Store involves much more than running a single build command. You must create a developer account, configure a polished store listing, generate a production-signed Android App Bundle (AAB), and navigate Google's multi-tier review tracks before millions of users can install your app. This lesson walks through every step in the correct order.
Step 1 — Create a Play Console Developer Account
Before you can publish anything, you need a Google Play Console account. Go to play.google.com/console, sign in with a Google account, and pay the one-time $25 registration fee. Once your account is active you can create an app by clicking Create app, choosing a default language, and declaring whether it is an app or a game and whether it is free or paid.
Step 2 — Configure the Store Listing
A complete store listing is required before Google will review your app. The listing contains several sub-sections:
- App details — Short description (80 chars), full description (4,000 chars), and app name (30 chars) in every supported language.
- Graphics — A 512 × 512 px icon, a 1,024 × 500 px feature graphic, and at least two phone screenshots (minimum 320 px on the short side, maximum 3,840 px on the long side).
- Content rating — Fill in the IARC questionnaire; Google assigns age-appropriate ratings (e.g., Everyone, Teen, Mature 17+) for each country automatically.
- Data safety — Declare every type of data your app collects or shares (location, contacts, financial info, etc.) and whether it is encrypted in transit. This section is mandatory and displayed prominently to users on your store page.
- App category and contact details — Choose the most accurate category and provide a privacy policy URL (required for all apps).
Step 3 — Generate a Production-Signed AAB
Google Play requires an Android App Bundle (.aab) rather than a raw APK for new apps. An AAB lets Play generate optimised APKs per device, reducing download sizes by up to 65%. You must sign the bundle with a keystore you control. The signing process has two parts:
Part A — Create a keystore (one time only):
Generate a Release Keystore
# Run from your terminal (not inside the Flutter project)
keytool -genkey -v \
-keystore ~/keys/my-release-key.jks \
-keyalg RSA \
-keysize 2048 \
-validity 10000 \
-alias upload
# You will be prompted for:
# - Keystore password
# - Key alias password
# - Distinguished name (first/last name, org, city, country)
#
# WARNING: Back this file up securely.
# Losing it means you can never update your app on Play.
Part B — Wire the keystore into Flutter:
android/app/build.gradle (signing config)
// android/key.properties (never commit this file!)
// storePassword=my-store-password
// keyPassword=my-key-password
// keyAlias=upload
// storeFile=/Users/me/keys/my-release-key.jks
// android/app/build.gradle
def keystoreProperties = new Properties()
def keystorePropertiesFile = rootProject.file('key.properties')
if (keystorePropertiesFile.exists()) {
keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
}
android {
signingConfigs {
release {
keyAlias keystoreProperties['keyAlias']
keyPassword keystoreProperties['keyPassword']
storeFile keystoreProperties['storeFile'] ?
file(keystoreProperties['storeFile']) : null
storePassword keystoreProperties['storePassword']
}
}
buildTypes {
release {
signingConfig signingConfigs.release
minifyEnabled true
shrinkResources true
}
}
}
Once signing is configured, build the AAB:
Build a Release AAB
# Clean first to avoid stale artefacts
flutter clean
# Build the release AAB
flutter build appbundle --release
# Output: build/app/outputs/bundle/release/app-release.aab
# Upload this file to Play Console
key.properties or your .jks keystore file to version control. Add both to .gitignore immediately. If your signing key leaks, a bad actor could publish malicious updates under your app identity.Step 4 — Understand the Review Tracks
Google Play uses a graduated release system with four tracks. You must progress through them in order, and each track has different audiences and review requirements:
- Internal testing — Up to 100 testers you invite by email. Review is usually approved within minutes. Ideal for team smoke tests immediately after a build.
- Closed testing (Alpha) — Invite-only testers (unlimited via groups or email lists). Requires a full policy review the first time. Use this for beta testers and early adopters before wider rollout.
- Open testing (Beta) — Any Google account holder can opt in via your public beta link. Still requires passing Google's content review. Generates user reviews tagged "Early Access" on your listing.
- Production — Live to all users. You can do a staged rollout — start at 1%, 5%, 20%, then 100% — to catch regressions before full exposure. Production submissions typically take 1–3 days for Google review on first submission.
Step 5 — App Signing by Google Play (Recommended)
When you upload your first AAB, Play Console will offer to enrol in Play App Signing. Google securely stores your app signing key and re-signs your bundle at delivery time. Your keystore becomes an upload key only — even if someone steals your upload key, they cannot publish without Play's server-side signing key. This is the strongly recommended approach for new apps.
Summary
Publishing to Google Play is a multi-step process: set up your Play Console account, complete the store listing (metadata, graphics, content rating, data safety), generate a production-signed AAB using a securely stored keystore, and roll out through the four review tracks from Internal to Production. Taking each step deliberately — especially signing key management and staged rollouts — greatly reduces the risk of a painful first launch.