How to Prepare Flutter App for Google Play Store

Preparing a Flutter Android app for release on Google Play

Preparing a Flutter app for Google Play is more than generating an APK. A production release needs a permanent application identity, controlled signing, a compliant target API, accurate privacy declarations, tested release behavior, and a store listing that matches what the app actually does.

This guide follows the release in the same order a developer should: freeze the app identity, audit code and permissions, configure signing, build an Android App Bundle, test it through Google Play, and complete the policy declarations before production.

Start with a Release Candidate, Not an Unfinished Build

Create a dedicated release branch or Git tag before changing signing and store configuration. The app should already have its critical features, error handling, privacy behavior, and automated tests in place.

Run a baseline check from the project root:

dart format .
flutter analyze
flutter test
flutter doctor -v

Resolve errors rather than suppressing them for release. If the Android build system fails, work through How to Fix Flutter Gradle Build Errors before changing signing keys or Play Console settings.

Step 1: Confirm the Permanent Application ID

The Android applicationId uniquely identifies the app on Google Play and on users' devices. A common format is a reverse domain name, such as com.example.taskapp, but production apps should use an identifier controlled by the developer or organization.

Review the Android app configuration in android/app/build.gradle.kts or the equivalent Gradle file:

defaultConfig {
    applicationId = "com.example.taskapp"
}

Replace the example with the real identifier before the first Play upload. After an app is published under an application ID, changing it creates a different Android app rather than a normal update. Also confirm that the Android namespace and MainActivity package structure are consistent with the project configuration.

Step 2: Set the App Version Correctly

Flutter normally reads the release version from pubspec.yaml:

version: 1.0.0+1

The part before + is the user-visible version name. The number after it becomes the Android version code. Increase the version code for every new Play upload; Google Play rejects an artifact that reuses a version code already uploaded for that app.

Use a versioning system your team can reproduce. Do not edit the number manually in several different Android files unless the build process explicitly requires it.

Step 3: Meet the Current Target API Requirement

Google Play requires new apps and updates to target a recent Android API level. Starting 31 August 2026, new mobile apps and app updates submitted to Google Play must target Android 16, API level 36, or higher. Other form factors such as Wear OS, Android TV, Android XR, and Android Automotive can have different requirements.

Because this policy changes over time, check the current Target API Level Policy immediately before uploading. Also test behavior changes introduced by the target Android version rather than changing only the number to pass Play Console validation.

Install the required platform and build tools through Android Studio's SDK Manager, then validate the project:

flutter doctor -v
flutter analyze
flutter build appbundle

Step 4: Audit Android Permissions

Review android/app/src/main/AndroidManifest.xml and every plugin that contributes manifest entries. Remove permissions that are not required for a visible feature.

Pay particular attention to:

Location, camera, microphone, contacts, SMS, call log, and notifications.
Accessibility services and package visibility.
Background location or background services.
Storage and media access.
Advertising identifiers and analytics SDKs.

A permission declaration, the in-app request, the privacy policy, Data safety answers, and the feature shown to reviewers must tell the same story. Do not request a sensitive permission at startup when it is needed only for an optional feature.

Step 5: Audit Data Collection by Every SDK

Create an inventory of data processed by your own code and third-party SDKs. Include analytics, ads, crash reporting, authentication, cloud databases, payments, notifications, maps, and social-login packages.

For each data type, record:

What is collected or shared.
Whether collection is required or optional.
Why the data is used.
Whether data is encrypted in transit.
How users can request deletion when applicable.
Which external SDK or service receives it.

Google Play requires developers to complete the Data safety form, including the behavior of third-party libraries. Even an app that collects no user data must generally complete the form and provide a privacy policy when it is distributed beyond internal testing.

Step 6: Publish an Accurate Privacy Policy

The privacy policy must describe the app's real behavior. It should identify the developer, data collected, purposes, sharing, retention, security practices, user choices, deletion process, children's handling where relevant, and contact method.

Host it at a public, active, non-geofenced URL that reviewers and users can open. Apps handling personal or sensitive data may also need the privacy policy inside the app and a prominent in-app disclosure immediately before certain unexpected data access.

A generic website policy is not automatically sufficient for an Android app. Use How to Create Privacy Policy for Blogger as a publishing starting point, but rewrite the contents to match the app, its SDKs, and its data flows.

Step 7: Create and Protect the Upload Key

Android applications must be digitally signed. With Play App Signing, Google manages the app signing key used for distribution, while the developer normally signs uploads with an upload key.

On Windows PowerShell, a new upload keystore can be created with keytool using a command similar to:

keytool -genkey -v -keystore "$env:USERPROFILE\upload-keystore.jks" -storetype JKS -keyalg RSA -keysize 2048 -validity 10000 -alias upload

Choose strong passwords and store the keystore and recovery information in secure backups. Never upload the keystore, passwords, or key.properties to a public repository, shared chat, or AI prompt.

Configure release signing by following the current Flutter Android deployment guide for your project's Gradle format. Flutter projects may use Kotlin DSL or older Groovy files, so copying a signing block from the wrong project layout can create avoidable build errors.

Step 8: Review Release Configuration

Before building, check:

Final app name and launcher icon.
Unique application ID and namespace.
Version name and increased version code.
Minimum and target SDK values.
Required permissions only.
Release API endpoints instead of test servers.
No debug banners, test accounts, sample data, or verbose sensitive logging.
Signing secrets excluded from source control.

Search the project for development URLs, placeholder keys, and TODO items. Confirm that production services use the correct security rules and that release builds do not depend on a local computer.

Step 9: Build the Android App Bundle

Google Play prefers the Android App Bundle format. From the project root:

flutter clean
flutter pub get
flutter analyze
flutter test
flutter build appbundle

The normal output path is:

build/app/outputs/bundle/release/app.aab

Read the complete build output. A generated file is not proof that signing, privacy, permissions, or runtime behavior are correct. Keep the exact source commit associated with the bundle so the release can be reproduced.

Step 10: Test the Distributed Release

Create an internal testing release in Play Console and upload the signed .aab. Install the app using the tester link so you exercise Google's generated APK delivery rather than only a local debug build.

Test these areas on real devices:

Fresh installation and first launch.
Upgrade from a previous version.
Login, logout, password reset, and account deletion if offered.
Denied, accepted, and permanently denied permissions.
Offline, slow-network, server-error, and empty states.
Notifications, background behavior, deep links, and file access.
Payments, ads, analytics consent, and privacy controls.
Release performance and crash reporting.

Testing only with flutter run is insufficient because debug mode and a Play-distributed release can behave differently.

Step 11: Prepare the Store Listing

Create store assets that accurately represent the app:

App name, short description, and full description.
High-quality app icon and feature graphic.
Screenshots from the current release.
Support email and developer website.
Privacy policy URL.

Do not use screenshots of features that are missing, fake ratings, misleading performance claims, trademarked branding you do not control, or keyword-stuffed descriptions. Check the current Play Console asset specifications before exporting graphics because required dimensions can change.

Step 12: Complete the App Content Declarations

In Play Console's App content section, complete every declaration that applies. This can include:

Privacy policy.
Ads declaration.
App access and reviewer login instructions.
Target audience and content.
Content rating.
Data safety.
Sensitive permissions or API declarations.
News, health, financial, government, or other category-specific forms.

If reviewers cannot reach a restricted feature, provide a working review account and clear steps. Ensure the declaration matches every active version and SDK distributed through Google Play.

Final Flutter Google Play Checklist

The application ID is final and unique.
The version code is higher than every previous upload.
The target API meets the requirement on the submission date.
Only necessary permissions remain.
All SDK data practices have been audited.
The privacy policy and Data safety form match the app.
The upload key is backed up and excluded from source control.
flutter analyze and flutter test pass.
The signed app bundle builds successfully.
The Play-distributed release has been tested on real devices.
Store assets and App content declarations are complete and accurate.

For the broader development workflow leading up to this release, use the Flutter Android App Development Guide. When testing APKs outside Google Play for your own development workflow, follow How to Install APK Safely on Android.

Official References

Google Play policies, target API deadlines, declarations, and testing requirements change over time. This guide was reviewed against official Flutter and Google Play documentation available on 23 August 2026; confirm the current Play Console requirements before every submission.