Flutter • Android • Google Play Console

How to Publish a Flutter App on the Google Play Store: A Complete Step-by-Step Guide

Prepare, sign, test, and publish your Flutter Android app—from the first release build to a production rollout.

Who is this guide for? Flutter developers publishing an Android app for the first time or preparing a new release. It covers project configuration, secure signing, the Android App Bundle, Play Console setup, testing, store listing, policy forms, and production release.

Important for 2026: As of October 2026, Google Play's published requirement says new mobile apps and app updates must target Android 16 (API level 36) or higher beginning August 31, 2026. Verify the current target API requirement in Play Console and Google's policy page before uploading, since requirements can change.

Publishing workflow at a glance

🛠️

1. Prepare

Project and version

🔐

2. Sign

Upload keystore

📦

3. Build

Android App Bundle

🚀

4. Publish

Test and release

1. Prepare your development environment

Make sure Flutter and the Android toolchain are installed and configured. Run these commands from your terminal:

flutter doctor -v
flutter --version
flutter pub get

Resolve important Android SDK, Java, Gradle, or dependency problems before creating a release. Run your tests and analyzer as well:

flutter analyze
flutter test

Test the app on a physical Android device. Check login, network failures, deep links, notifications, permissions, purchases, and other important user journeys—not just the happy path.

2. Choose your application ID

The Android applicationId is the permanent identifier Google Play uses for your app. A typical value looks like com.example.myflutterapp, but you should replace it with your own reverse-domain identifier before your first upload.

Open the android/app/build.gradle or android/app/build.gradle.kts file, depending on your project.
Find the applicationId inside the app module's defaultConfig.
Set it to your intended production ID and check that your Kotlin or Java package structure is consistent where relevant.

Example for a Kotlin Gradle file:

android {
    namespace = "com.example.myflutterapp"

    defaultConfig {
        applicationId = "com.example.myflutterapp"
        // Keep the Flutter-generated SDK values unless
        // you have a reason to change them.
    }
}

Important: Once an app is published, you cannot change its application ID and continue updating the same Play Store listing. Confirm it before your first release.

3. Set the app name, icon, and permissions

Update your launcher icon using your preferred icon-generation workflow. Confirm the generated assets are in the Android resource directories and test the icon on a device. Set the user-visible app name in the Android manifest or appropriate resource configuration.

Review android/app/src/main/AndroidManifest.xml and remove permissions your app does not need. For sensitive features, request runtime permission when required and explain the reason in context. Google Play may ask for additional declarations for permissions or APIs such as background location, SMS, call logs, or broad photo/video access.

Make sure your screenshots and store listing represent the actual app, and remove template screens, test labels, and broken links before submission.

4. Set version name and version code

In your Flutter project's pubspec.yaml, set a release version:

version: 1.0.0+1

In this example, 1.0.0 is the user-facing version name and 1 is the build number. On Android, Flutter maps these values to the version name and version code. Every uploaded update needs a version code higher than previous releases.

You can override the values when building:

flutter build appbundle --release \
  --build-name=1.0.0 \
  --build-number=1

For each new upload, increment the build number, for example to 2, 3, and so on.

5. Create a secure upload keystore

Google Play App Signing manages the app signing key used to distribute installs. You still need to sign the app bundle you upload with an upload key. Keep the upload keystore and its passwords secure, backed up, and out of source control.

Create an upload keystore with Java's keytool. Adjust the filename and validity to your organization's policy:

keytool -genkey -v \
  -keystore ~/upload-keystore.jks \
  -keyalg RSA -keysize 2048 -validity 10000 \
  -alias upload

Follow the prompts and record the keystore password, key password, and alias in a secure password manager. Do not commit the keystore or passwords to GitHub or share them in screenshots.

Configure the key properties

Create android/key.properties and fill in your own local values:

storePassword=YOUR_STORE_PASSWORD
keyPassword=YOUR_KEY_PASSWORD
keyAlias=upload
storeFile=/absolute/path/to/upload-keystore.jks

Use the actual path to your keystore. Add android/key.properties and the keystore to your Git ignore rules. Never replace the placeholders above with real credentials in a public article or repository.

Configure signing in Gradle

Flutter's Android template may use Kotlin DSL (build.gradle.kts) or Groovy (build.gradle). Follow the current Flutter signing guide for the exact syntax in your project. The essential setup is to load key.properties, create a release signing configuration, and assign it to the release build type. Do not paste Kotlin DSL syntax into a Groovy file or vice versa.

After configuring signing, verify that a release build is signed with your upload key. Keep a secure backup of the key and follow Google's recovery process if your upload key is ever lost or compromised.

6. Check the target Android API level

Google Play enforces target API level requirements to ensure apps meet current Android behavior and security expectations. As of October 2026, the published requirement for new mobile apps and updates is Android 16 (API level 36) or higher, effective August 31, 2026. Special categories such as Wear OS, Android TV, Automotive OS, and Android XR can have different requirements.

Check the targetSdk or targetSdkVersion setting in your app module's Gradle configuration and confirm the required Android SDK platform is installed. Flutter projects often reference values from the Flutter Gradle plugin; avoid blindly hard-coding values without checking the current official Flutter and Google Play instructions.

Official policy: Google Play target API level requirements.

7. Build the Android App Bundle (.aab)

Google Play recommends the Android App Bundle format. Play uses the bundle to generate APKs optimized for different device configurations. From your Flutter project root, run:

flutter clean
flutter pub get
flutter build appbundle --release

The bundle is usually generated at:

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

Use the exact path printed by your build output if your project configuration differs. Keep a copy of the release artifact and its corresponding source revision.

If you need an APK for direct testing or another distribution channel, you can build one separately:

flutter build apk --release

For Google Play publication, use the signed .aab unless your particular release workflow specifies otherwise. Do not upload a debug build.

8. Create your app in Google Play Console

Open Google Play Console and sign in with your developer account.

Choose Create app.
Enter the app name and default language.
Choose whether it is an app or a game, and whether it is free or paid.
Complete the required declarations and confirm the relevant developer program terms.
Open the app dashboard and follow the setup tasks shown for your app.

Some account types must complete verification or specific testing steps before production access. In particular, personal developer accounts created after November 13, 2023 are subject to Google Play's testing requirements. Check the current requirements shown in your Play Console dashboard before planning your launch date.

9. Complete the store listing

Prepare a clear, accurate listing that helps users understand the app. Depending on your app, Play Console may ask for:

App name, short description, and full description.
App icon and feature graphic.
Phone, tablet, or other supported-device screenshots as applicable.
App category, tags, and contact details.
Website and support contact information.
Privacy policy URL where required.

Use genuine screenshots of your app, follow the current image dimensions and file requirements, and avoid unsupported claims such as guaranteed results or misleading rankings. Do not use another developer's brand or images without permission.

10. Complete App content and policy declarations

Open the App content or policy section in Play Console and complete every declaration that applies. Depending on the app, this can include:

Privacy policy: Explain the data your app collects, how it is used, and how users can contact you.
Data safety: Report data collection, sharing, security practices, and deletion options accurately—including behavior from third-party SDKs.
Ads: Declare whether the app contains ads.
App access: Provide review instructions or a test account if the app requires login or has restricted features.
Content rating: Complete the questionnaire accurately.
Target audience: Declare the intended audience and follow Families policies if children are included.
Sensitive permissions: Complete additional declarations if your app uses restricted permissions or APIs.
Financial features, health, news, or other regulated categories: Complete any applicable extra declarations.

Do not copy another app's Data safety answers. Your disclosures must match your code, backend, SDKs, and actual data practices. Review Google's current Developer Program Policies before release.

11. Test before production

Google Play provides testing tracks that let you distribute a build before making it generally available:

Internal testing

Quick checks with a small group of trusted testers. Useful for verifying that the uploaded bundle installs and launches.

Closed testing

Test with a selected group, gather feedback, and satisfy applicable account-specific testing requirements.

Open testing

Make a test version available to a broader audience when the track is available to your app.

Upload the AAB to a testing track, add testers, and share the opt-in link or instructions. Test on several Android versions and screen sizes, including a lower-end device if possible. Verify sign-in, notifications, deep links, purchases, permissions, offline states, and app updates.

12. Create a production release

In Play Console, open Test and release → Production (menu names may vary).
Create a new release.
Upload the signed .aab if the build is not already available to select.
Add release notes describing the version's changes.
Review warnings, policy tasks, and required declarations.
Save the release and follow the console's review and rollout steps.

Play Console may block rollout until required setup tasks, testing requirements, policy declarations, or review checks are complete. Read the message shown in the console and resolve each blocking item.

13. Roll out and monitor your app

When your release is eligible, review the countries or regions, release notes, and final version details, then start the rollout. A first production release may become available across the selected regions after processing; availability can take time and is not always instantaneous.

After launch, monitor Android vitals, crash reports, ratings, reviews, support requests, and backend errors. If a serious issue appears, prepare a fixed build with a higher version code and follow the appropriate release process. For later updates, repeat testing and increment the build number.

14. Common publishing problems

Problem	What to check
Upload rejected due to version code	Increase the Flutter build number so the Android version code is higher than previous uploads.
Signing error	Check keystore path, alias, passwords, Gradle signing configuration, and that the release variant uses the upload key.
Wrong target API	Verify the current Play policy and installed SDK platform; do not rely on an old project template.
App crashes on launch	Test the release build, check plugin compatibility, initialization, production configuration, and device logs.
Policy or Data safety issue	Review permissions, SDK collection, privacy policy, declarations, and the relevant Play policy.
Production access unavailable	Check whether your developer account must complete verification or a required testing track first.

15. Final pre-launch checklist

☐ Flutter analyzer and automated tests pass.
☐ App ID, app name, icon, and permissions are correct.
☐ Version name and unique version code are set.
☐ Upload keystore is backed up securely and excluded from source control.
☐ Release build is signed and the AAB is generated successfully.
☐ Target API level meets the current Google Play requirement.
☐ App has been tested on real devices and through a Play testing track.
☐ Store listing, screenshots, and support information are complete.
☐ Privacy policy and Data safety declarations are accurate.
☐ Content rating, ads, target audience, and app access declarations are complete.
☐ Account verification and any required testing prerequisites are satisfied.
☐ Production rollout regions and release notes have been reviewed.

Conclusion

Publishing a Flutter app on Google Play is a repeatable process: prepare and test your project, configure the application ID and secure signing, build a release Android App Bundle, complete Play Console declarations, test through an appropriate track, and roll out the production release. Keeping your signing credentials safe, checking current target API rules, and testing the release build before launch will help prevent common publishing delays.

Official resources

Google Play Console requirements and Flutter/Android build tooling evolve. Confirm current policy and version requirements in official documentation before uploading.

Flutter Learning

Search This Blog