PeerPlay
To get a FlutterFlow app onto the Play Store from a new personal developer account, deploy it to internal testing as FlutterFlow's docs describe, then promote that release to a closed testing track in Play Console and keep at least 12 testers opted in for 14 days in a row. Only after that can you apply for production.
FlutterFlow's deployment guide goes from internal testing straight to Promote Release and Production. It never mentions the closed test, so many FlutterFlow users only discover the requirement when Play Console won't let them release. Here's the full path with that missing step added.
Step 1: set up FlutterFlow Play Store deployment
Create the app in Play Console first, and double-check the package name in FlutterFlow. The docs warn that it can't be changed after your app is deployed. Your launcher icon also must not have transparency.
Then give FlutterFlow permission to upload for you. In Google Cloud Console, enable the Google Play Developer API, create a service account and download a JSON key for it. In Play Console, invite that service account under Users and permissions with rights to release to testing tracks and production. Finally, in FlutterFlow open Settings & Integrations, App Settings, Mobile Deployment, and upload the file under Service Account Credentials in the Google Play Store section.
Step 2: upload the first AAB by hand
FlutterFlow can't make the very first upload for you. Its docs say that for a fresh deployment you download the .aab from FlutterFlow and upload it to the internal testing track yourself. Set Google Play Track to Internal, start the deploy, wait for the build, and download the AAB from the build status.
In Play Console, open Internal testing, create a release and upload that file. Once the internal track has a build, FlutterFlow handles later releases with one click.
FlutterFlow generates the keystore and signs the app for you. Download a copy of that keystore from the deployment settings and keep it somewhere safe. If you previously published the app with your own keystore, enable the Upload Keystore option under Advanced Settings and provide the file and its alias, or Play Console will reject the bundle as signed with the wrong key.
Step 3: move the release to closed testing
This is the step the FlutterFlow docs skip. Google requires personal developer accounts created after November 13, 2023 to run a closed test with at least 12 testers opted in for the last 14 days continuously before applying for production access. Internal testing doesn't count toward it, and organization accounts are exempt.
In Play Console, go to Testing, then Closed testing, and create a track or use the default one. Then promote your internal release to it: open the internal release, choose Promote release and pick the closed track. You're reusing the same build FlutterFlow already uploaded, so nothing changes in your project.
Add testers to the closed track with an email list or a Google Group and send them the opt-in link. Invite 15 to 20 people. The 14 days only count while 12 or more are opted in, and a few will always drop out.
Step 4: ship updates during the 14 days
When testers find a bug, fix it in FlutterFlow and deploy again. FlutterFlow raises the build number, which is the Android version code, on every deploy, so you won't hit a duplicate version error.
The documented flow sends each new build to the internal track. After it arrives, promote it to your closed track the same way as before so your testers get the update. Keep the same closed track and tester list for the whole test.
Fixing common FlutterFlow deploy errors
"Only releases with the status draft may be created on a draft app." Your Play Console app hasn't finished setup yet. FlutterFlow's docs say to enable Submit as draft under Advanced Settings, then roll out the release manually in Play Console.
"Changes cannot be sent for review automatically." Enable the Changes not sent for review option in FlutterFlow and deploy again, then send the changes for review yourself in Play Console.
A wrong signing key error means the bundle was signed with a different key than Play Console expects. Check whether the app was first uploaded with another keystore, and if so use the Upload Keystore setting described above.
Step 5: apply for production
After 14 days with 12 or more testers opted in, apply for production access from the Play Console Dashboard. Google asks how you tested and what you changed, so keep notes on tester feedback. Once access is granted, promote the release to Production and switch Google Play Track to Production in FlutterFlow.
If you can't find 12 people who will stay for two weeks, PeerPlay is a free way to swap tests with other Android developers, and paid VIP packages are available if you'd rather skip the swaps.
FAQ
Does FlutterFlow's internal testing track count toward the 12 testers?
No. Google's requirement is a closed test with at least 12 testers opted in for 14 days in a row. Promote your internal release to a closed testing track in Play Console.
Why do I have to upload the first AAB manually?
FlutterFlow's docs say the first build of a fresh deployment must be downloaded and uploaded to the internal testing track by hand. After that, FlutterFlow can deploy later releases for you.
Do I need to change the build number myself?
No. FlutterFlow says it auto-increments the build number, which is the Android version code, on every deploy. You can still edit the version and build number if you need to.
Where is my FlutterFlow keystore?
FlutterFlow generates it automatically and lets you download it from the Google Play deployment settings. Keep a backup.