Izz: How to Prepare a Flutter App for Google Play Store in 2026

Updated: September 2026

Getting a Flutter app to compile is not the same as getting it ready for Google Play.

A Play Store release needs a correct Android target API level, release signing, versioning, an Android App Bundle, policy disclosures, store assets, testing and a final production check.

This guide covers the practical release path for a Flutter Android app in 2026.

2026 Requirement to Know First

Starting August 31, 2026, new Android apps and app updates submitted to Google Play must target Android 16 / API level 36 or higher.

Do not prepare a new release around an older target SDK and assume Play Console will accept it.

Flutter to Google Play: Release Checklist

Area	What to Check
Target API	Android 16 / API 36 or higher for new apps and updates in 2026
Versioning	Correct version name and increasing version code
Signing	Release upload key configured correctly
Build format	Signed AAB for Google Play
Permissions	Only permissions your app genuinely needs
Privacy	Privacy Policy and Data safety answers match real app behavior
Testing	Release build tested on real hardware
Store listing	Icon, screenshots, description and feature graphic ready

1. Make Sure Your App Targets the Required Android API

Google Play updates its target API requirements regularly.

For normal Android mobile apps, starting August 31, 2026:

New apps must target Android 16 / API 36 or higher.
App updates must target Android 16 / API 36 or higher.

Flutter projects often use Flutter-managed Android SDK values, so do not automatically hardcode random SDK versions into Gradle files unless the project actually needs an override.

Check your generated Android configuration and confirm the final release meets Google Play's current requirement.

2. Review Your Application ID

The Android application ID uniquely identifies the app on Google Play.

Example:

com.example.myapp

Choose it carefully before publishing.

Once an app is published under a package name, changing that application ID effectively creates a different app from Google Play's perspective.

3. Set the App Version Correctly

Flutter normally stores version information in pubspec.yaml.

Example:

version: 1.2.0+12

This represents:

1.2.0 — user-facing version name
12 — Android version code

The version code must increase for each new Play Store release.

4. Configure Release Signing

Google Play requires a signed release build.

Flutter's Android release workflow uses an upload key for the artifact you upload to Play Console.

Keep the private signing key secure.

Typical release configuration includes:

Keystore file
Key alias
Key password
Store password
key.properties

Never commit passwords or private keystore files to a public Git repository.

5. Understand Play App Signing

Google Play uses Play App Signing to manage the app signing key used for distribution to end users.

You typically upload an app bundle signed with your upload key, while Google handles the app signing key used for distributed APKs.

This separation means losing your upload key is different from losing the app signing key.

6. Review Android Permissions

Before release, inspect the permissions your app requests.

Do not keep permissions simply because a plugin once required them.

Ask:

Does the app still use this feature?
Does the permission appear in AndroidManifest.xml?
Does a third-party plugin add it automatically?
Does Google Play require a declaration for that permission?

Unnecessary permissions can create policy and user-trust problems.

7. Check Data Safety Before You Upload

Google Play's Data safety form should describe what the app actually collects and shares.

That includes data handled by third-party SDKs.

Examples can include:

Analytics SDKs
Advertising SDKs
Crash reporting
Location services
Authentication providers
AI or cloud APIs

Do not answer the Data safety form based only on code you personally wrote.

Dependencies matter too.

8. Add a Privacy Policy When Required

If the app handles user data, uses ads, analytics, accounts or sensitive permissions, make sure the Privacy Policy reflects the real behavior of the app.

The store listing and in-app privacy disclosures should not contradict each other.

9. Build a Release Android App Bundle

Google Play prefers the Android App Bundle format.

From the Flutter project root, run:

flutter build appbundle

A successful release normally produces:

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

Flutter's current Android deployment documentation identifies the app bundle as the preferred Play Store release format.

10. Do Not Upload an Untested Release Build

A debug build can behave differently from a release build.

Before uploading, test the release configuration on real Android hardware.

Check:

App startup
Login
Network calls
Notifications
Deep links
Permissions
Purchases if used
Ads if used
Background behavior

11. Check Release-Only Problems

If debug works but the AAB build fails, investigate release-specific settings.

Common causes include:

Signing errors
Missing release environment variables
R8 shrinking issues
ProGuard configuration
Plugin release configuration
API keys restricted incorrectly

12. Review the Android Manifest

Before publishing, inspect the final Android manifest behavior.

Check:

Permissions
Activities
Intent filters
Deep links
Services
Receivers
Exported components

Plugins can add manifest entries automatically, so reviewing only your own manifest file may not reveal the complete final result.

13. Prepare the Store Listing

A technically correct AAB is not enough.

Prepare:

App name
Short description
Full description
High-resolution app icon
Feature graphic
Phone screenshots
Tablet screenshots when relevant
Privacy Policy URL

Do not use screenshots that show features the production app does not actually contain.

14. Complete the Content Rating

Google Play requires apps to have an appropriate content rating.

Answer the questionnaire based on the real app, including user-generated content, gambling themes, violence, communication features or other relevant content.

15. Configure Target Audience Correctly

Target audience choices can affect which Google Play policies apply.

Do not select children's age groups simply to maximize visibility unless the app is genuinely designed for those users and complies with the relevant requirements.

16. Check Ads and Monetization Declarations

If your app contains ads, disclose that accurately in Play Console.

Also confirm your ad SDK configuration complies with Google Play policies and any age-related restrictions that apply to the app.

17. Test Through Google Play, Not Only Locally

Use a Play testing track before production.

Available testing approaches can include:

Internal testing
Closed testing
Open testing

Installing from Google Play can expose problems that do not appear when you sideload a local APK.

18. Understand Closed Testing Requirements

Some personal developer accounts may need to satisfy Google Play testing requirements before production access is granted.

Requirements can depend on account status and current Play Console rules.

Check the production-access section of your own Play Console rather than relying on an old tutorial, because eligibility requirements can change.

19. Check Pre-Launch Reports

Google Play can test uploaded builds across devices and configurations.

Review pre-launch results for:

Crashes
ANRs
Layout problems
Compatibility issues
Security warnings

Do not ignore a serious pre-launch failure simply because the app works on your own phone.

20. Review App Access Requirements

If reviewers cannot access important parts of the app without signing in, provide valid review instructions or credentials where Play Console requires them.

An app that reviewers cannot properly evaluate can delay release.

21. Check for Policy-Sensitive SDKs

Third-party SDKs can create compliance problems even when your own code looks fine.

Review SDKs related to:

Advertising
Location
Analytics
Payments
AI services
User tracking

Developers remain responsible for app behavior introduced by dependencies.

22. Verify the Final AAB Before Upload

Release Sanity Check

Correct package name

Correct version

API 36+ target where required

Release signing works

AAB builds successfully

Release build launches

Critical features work

Permissions are justified

Privacy Policy is accurate

Data safety answers match app behavior

Store assets match the production app

Flutter Google Play Release Diagnostic Table

Problem	Likely Area	Check First
Play rejects target API	Android SDK config	Target API requirement
AAB will not build	Gradle / signing	First meaningful build error
Version already used	Versioning	Version code
Release crashes	Release config	Release-only dependencies and logs
Policy warning	App or SDK behavior	Exact Play Console policy message
Review cannot access app	App access	Review credentials/instructions

Final Release Workflow

Confirm the app meets the current target API requirement.
Update version name and version code.
Review permissions and dependencies.
Check signing.
Build the AAB.
Test the release build on real hardware.
Prepare store listing assets.
Complete Data safety and policy declarations.
Upload to a testing track.
Review Play Console warnings and pre-launch reports.
Only then move toward production.

Final Thoughts

Publishing a Flutter app to Google Play is not just a build command.

The technical release, store listing and policy configuration all need to describe the same real application.

For 2026, one of the most important checks is the target API requirement: new apps and app updates for standard Android mobile devices must target Android 16 / API 36 or higher from August 31.

Prepare the release systematically, test the actual AAB workflow and treat Play Console warnings as part of development rather than paperwork after development is finished.

Continue the Flutter Android Series

Official Sources & Further Reading

Flutter — Build and Release an Android App

Google Play — Target API Level Requirements

Google Play — Prepare and Roll Out a Release

2026 Requirement to Know First