Google Play closed testing for FlutterFlow apps

FlutterFlow (its docs now call the visual builder FlutterFlow Studio) can deploy to Google Play from inside the builder. Its documented path is: first upload to the Internal testing track, then promote to Production (FlutterFlow docs).

That path skips the step Google requires from new personal accounts. If your Play Console account is personal and was created after November 13, 2023, Production stays disabled until you run a closed test with at least 12 testers opted in for 14 continuous days and Google approves your production access application (Play Console Help). This page shows how to fit a closed test into FlutterFlow's flow. For the rule itself, see the closed testing guide.

Settings you can't undo

Check these before the first deployment:

• Package name. FlutterFlow warns that it can't be changed after your app is deployed. When you create the app in Play Console, Google also registers that package name to your account for Android developer verification (Android Developers).
• Launcher icon. FlutterFlow's prerequisites say it can't be transparent or contain an alpha channel.
• Play Console setup tasks. FlutterFlow tells you to finish every task under "Set up your app" in Play Console before deploying. Skipping them is the most common cause of the draft error below.

Connect FlutterFlow to Play Console

FlutterFlow deploys through a Google service account (FlutterFlow docs):

1. In Google Cloud Console, enable the Google Play Developer API and create a service account with a JSON key.
2. In Play Console, go to Users and permissions, invite the service account email, and grant "Edit and delete draft apps", "Release to production…", "Release apps to testing tracks" and "Manage testing tracks and edit tester lists".
3. In FlutterFlow, open Settings & Integrations > App Settings > Mobile Deployment and upload the JSON under Service Account Credentials.

First release: put the AAB on the closed track

FlutterFlow's guide says that for the first deployment you download the AAB and upload it yourself; after that, FlutterFlow can handle releases (FlutterFlow docs).

1. In FlutterFlow, set the Google Play Track and click Deploy to Play Store.
2. Wait, click Check Build Status, then download the AAB.
3. In Play Console, go to Test and release > Testing > Closed testing > Manage track and create a release with that file. FlutterFlow's troubleshooting page confirms the first manual upload can go to Internal, Closed, Open or Production (FlutterFlow docs). Pick Closed.
4. In the Testers tab, add your testers (email list or Google Group), choose countries, save, and send the changes for review.

If the deploy in step 1 fails with "Package not found", that's expected on a first deployment. FlutterFlow lists it as a first-upload symptom; the AAB is still downloadable.

Why not use FlutterFlow's default Internal track for testers? Internal testing doesn't count for Google's requirement. And Google says a user who opts into your internal test is no longer eligible to receive your closed test (Play Console Help). Keep internal for your own devices. The internal vs closed vs open guide explains the tracks.

Updates during the 14 days

You'll fix things while the test runs. Google recommends it, and the production form asks what you changed (Play Console Help).

• FlutterFlow auto-increments the Build Number (Android versionCode) on every deploy, so you don't need to bump it by hand.
• FlutterFlow's guide documents the Internal and Production track settings. If the track menu in your project doesn't offer your closed track, download the AAB from each build and upload it to the closed track in Play Console. Or deploy from GitHub with your own pipeline.
• Don't push a fix to Internal and expect your closed testers to get it. They only receive what's on the closed track (or a higher version code in production, which you don't have yet).

The keystore is yours to back up

FlutterFlow auto-generates an upload keystore and signs every release with it. Its guide says you can download the keystore with the orange key button (FlutterFlow docs). Do it before the first release. If you previously shipped this app with your own keystore, turn on Upload Keystore in Advanced Settings and provide the alias instead.

With Play App Signing, Google can reset a lost upload key (Play Console Help). But developer verification can require proof that you own a package's signing key, and Google's FAQ says a lost signing key means you can't register your packages (Android Developers FAQ). A downloaded, backed-up keystore costs you one click.

Many FlutterFlow apps use Firebase Auth. Add the SHA-1 or SHA-256 of the Google-held app signing key (Play Console > Protected with Play > Play Store protection > Manage Play app signing) to Firebase. Google says API providers need that fingerprint, not just your upload key. Skip it and Google Sign-In can fail for every tester.

Target API 36: how to check a FlutterFlow build

Since August 31, 2026, new apps and updates must target API level 36 or higher (Play Console Help). FlutterFlow's docs don't publish the target SDK of generated projects, so check the code:

1. Export it (download the code, push to GitHub, or run flutterflow export-code --project <id> --dest <folder> with the FlutterFlow CLI (FlutterFlow docs)).
2. Open android/app/build.gradle.kts (or build.gradle) and find targetSdk.
3. If it reads flutter.targetSdkVersion, the value follows the Flutter version used to build. On Flutter's stable branch today (3.47), that's 36 (Flutter source).

On Enterprise plans, a project pinned to a stable FlutterFlow release doesn't receive updates, including Flutter upgrades, and each stable release is supported for six months (FlutterFlow docs). If your project is pinned, check the target SDK before you start the 14 days. The Flutter page covers the Gradle side in more detail.

FlutterFlow deployment errors and fixes

Before testers open the app

• Test on a real device first. FlutterFlow lists it as a prerequisite.
• If the app has a login, give testers working credentials and fill in App access in Play Console for Google's reviewers (Play Console Help).
• Keep the list of features you want tested short. You'll summarize the feedback in the production access application.

Timeline

• Service account and first manual upload: an evening, most of it in Google Cloud and Play Console screens.
• Google's first review: up to seven days or longer in exceptional cases for some new accounts (Play Console Help), then several hours before the opt-in link works.
• 14 continuous days of testing, then a production review that usually takes seven days or less (Play Console Help).

Count three to four weeks from first closed upload to your first Production deploy from FlutterFlow.