Publish a FlutterFlow App to Google Play: Draft, AAB, 12 Testers

The short answer: FlutterFlow makes the file, Play decides when it counts

Short answer: A FlutterFlow app reaches Google Play as a Flutter app bundle, but two steps sit between Send to testers and a running 14-day clock. Google accepts an app's first file only inside Play Console, so you upload that one .aab yourself. And the first test upload FlutterFlow sends afterwards is held as a draft release, which testers cannot install until you start its rollout in Play Console.

That second point is the one that costs days. The build reports as sent, the testers have been invited, nothing looks broken, and no opted-in time is accruing, because a draft release gives no one a link to opt in from.

This guide covers the whole path for both FlutterFlow products: the agent-based builder whose docs live under docs.flutterflow.io/ffx, and FlutterFlow Studio with its code export. It also covers the parts of the process FlutterFlow deliberately leaves to Play Console, which is where most of the real decisions are.

What FlutterFlow actually sends to Google Play

In the current product, Releases → Send to testers prepares the phone builds and uploads the Android version to your app's closed test. FlutterFlow builds from your app, not from a thread, so work you have not pushed is not in the build.

The Android output is a .aab (Android App Bundle). FlutterFlow signs it with an upload key it generates and auto-increments the build number, so you do not manage a keystore unless you want to download it. There is also a .apk download, but that is for installing on a phone yourself, not for Play: the bundle is what Play accepts.

File ceilings are documented and worth checking before a big asset push: 190 MB for the .aab, 95 MB for the sideload .apk, and a separate 30 MB cap on files bundled with the app itself.

Choose the App ID before you connect the stores

FlutterFlow calls the Android package name the App ID. It is the com.yourcompany.yourapp string that Play Console asks for as the package name, and it is the one setting in this whole process that cannot be undone.

FlutterFlow Studio's deployment docs put it plainly: confirm the app details, "especially the package name, which can't be changed after your app is deployed." The newer product's launch checklist adds the sequencing: save the App ID before you add the app in the stores, "because the stores' app records can't change it later."

Google states the same limit from its side, in the testing setup page: "Once you upload an artifact, the package name for that app is fixed and cannot be changed."

If you do change it after a store record exists, the store sees a different app. In Play that means a new app record, a fresh closed test, and a 14-day clock that starts from zero. In FlutterFlow it also means regenerating your Firebase config files, because the Firebase Android app is bound to the old package name.

The first upload is the one step FlutterFlow cannot do for you

Play's Publishing API can upload files to an app that already exists. It cannot create the app. That is the whole reason for the manual step, and it is why the first .aab goes up by hand.

1. In Play Console, select Create app and enter the App ID as the package name. FlutterFlow's Add your app in Play Console step displays every value it expects, with copy buttons.
2. Back in FlutterFlow, open the step and click Prepare Android app, then Download Google Play file to get the .aab.
3. In Play Console, open Internal testing, create a release with that file and complete it. This is what creates the app record FlutterFlow will find.
4. Return to the step in FlutterFlow. It looks for the app in Play Console and reports App found.

Do not confuse this with your actual test. Internal testing exists here to create the record. Google's requirement is specific about which track counts: "You must run a closed test before applying to publish your app to production." A closed test on internal testing is not a thing, and testers you invite to internal testing do not move the 12-tester count.

There is a sharper consequence, and it is easy to miss because FlutterFlow's first file lands on that track. Google: "A user who opts into your app's internal test is no longer eligible to receive an open or closed test. To access an open or closed test, the user must first opt out of the internal test and then opt in to the open or closed test." So any tester you already had opt in to internal testing is not merely uncounted, they are blocked until they opt out and back in on the closed track.

Once FlutterFlow finds the app, every later build is uploaded for you. You will not repeat this step for updates.

The draft release that quietly costs you the first days

A release in Play Console is not live the moment a file is uploaded. The first test upload FlutterFlow sends is kept as a draft, and FlutterFlow says so on its own troubleshooting page: "Google Play holds your first test upload as a draft until you start its rollout in Play Console."

The symptom is a Google Play card in FlutterFlow that reads Roll out 0.1 in Play Console, with your version number. Your testers have nothing to open, because a draft release has no opt-in link to install from. Later test uploads roll out automatically, so this happens once per app, at the worst possible moment.

Rolling out is necessary but not instantly visible. Google's setup page notes that after publishing a test for the first time, "the test link can take several hours to become available to testers." Set expectations with your group the same day rather than fielding "the link doesn't work" messages an hour after rollout.

Based on our analysis of 1,500+ closed-testing campaigns, a build reported as sent while Play Console still shows a draft is the most common way the first two days disappear. Nobody reports it as an error, because nothing errors. The developer waits for testers, and the testers wait for a link.

The sequence, in order: the point where the calendar starts is step 4, not step 1.

1. App created in Play Console, with the App ID as package name.
2. First .aab uploaded by hand to internal testing.
3. Closed test release created and testers added, by Google Group or email list.
4. First test upload rolled out. Before this point, the release is only a draft, and no opt-in link exists.
5. Testers open the opt-in link and install.
6. 12 testers stay opted in for 14 continuous days.
7. Apply for production access, then wait for Google's review.

Only steps 4 to 6 run the calendar. Steps 1 to 3 can sit unfinished for a fortnight without costing you a day, which is why doing them in one sitting is worth the effort.

The messages you will see, and what each one means

FlutterFlow mirrors Play's state on the Google Play card, so the card text is the fastest way to know which step you are standing on.

• Roll out 0.1 in Play Console — the first test upload is a draft. Testers have nothing to install and no opted-in time is accruing. Fix: open Play Console from the card and start the rollout of that test release.
• Apply for production access — test versions are accepted, but the account cannot release to everyone yet. Fix: meet 12 testers for 14 continuous days, then apply in Play Console.
• Google is reviewing your production access request — your application reached Google. Fix: wait. Google says review "usually takes seven days or less, but can occasionally take longer."
• Upload of 0.1 to Google Play failed — FlutterFlow built the version but Play refused the file. Fix: read the reason Play returned, fix what it names, then select Try again.
• App file too large — the bundle is over FlutterFlow's 190 MB .aab ceiling. Fix: move heavy assets out of the bundle. The sideload .apk ceiling is lower still, at 95 MB.

If you selected I've applied in FlutterFlow before actually applying, the card sits in a review state that Play does not know about. FlutterFlow provides the way back (I haven't applied yet), and it is worth using rather than waiting on a request that was never submitted.

Who FlutterFlow lists as a tester, and who Google counts

These are not the same list. FlutterFlow's Testers panel shows the Google Groups on your closed test, because those are what it can read back from Play. If you add testers through an email list in Play Console, FlutterFlow's docs are explicit: they "still get each version, but FlutterFlow doesn't list them."

Google counts something narrower than either list: opt-ins. From Google's testing requirements page: "At least 12 testers must be opted in to your closed test when you apply for production access, and they must have been opted in continuously for the preceding 14 days."

Invitations, group memberships and emails sent are all upstream of that. A tester who joined your Google Group but never opened the opt-in link is not opted in, and a tester who uninstalled and opted out stops counting from that moment. If Play Console shows fewer testers than you invited, the cause is almost always one of those two, and it is diagnosed in 0 Testers Currently Opted In.

FlutterFlow also does not keep your countdown. "FlutterFlow doesn't count the testers who opted in or the days for you," its docs state, so the authoritative start date is the one Play Console shows on the apply step. If you run more than one closed track, note that opting in is per test, not per tester, which is covered in multiple closed testing tracks.

Studio, code export, or the agent builder: same gate, different plumbing

FlutterFlow Studio deploys from the builder. You create a service account in Google Cloud, enable the Play Developer API, grant it access in Play Console, upload the JSON under Settings & Integrations → App Settings → Mobile Deployment → Google Play Store, set the track to Internal, and deploy. The same first-file rule applies: download the .aab from Studio and upload it to internal testing before the builder can publish on your behalf. Version codes auto-increment on each deploy, and you can still download a version code or the keystore if you need them.

Code export turns the project into a normal Flutter app. From there it is flutter build appbundle --release with your own keystore and Play App Signing, and the 12-tester rule is unchanged because it belongs to the account, not the toolchain. This is the path to take when you need custom native plugins or your own CI.

What makes FlutterFlow different from the web builders is the build output. Replit, Bolt, Lovable and v0 projects usually become web apps that need a wrapper shell before Play will take them, which brings in Digital Asset Links and app-signing fingerprints; that is the subject of assetlinks SHA-256 and Play App Signing. FlutterFlow produces native Flutter from the start, so there is no wrapper, no WebView and no asset-links file between you and the closed test. The gate that remains is the 14 days, which is the same gate described in Publish a Replit App to Google Play.

Five ways the 14 days get wasted in a FlutterFlow build

• The draft was never rolled out. The card said sent; Play said draft. Nothing accrues until step 4 of the sequence above.
• Testers were added to internal testing. Internal testing is optional, does not satisfy the closed-test requirement, and a tester who opts into it must opt out before they can opt into your closed test.
• Invited, not opted in. Twelve invitations produce zero opted-in testers until each person opens the link and installs.
• The App ID changed after the first upload. A new package name means a new Play record and a new clock, and it also breaks the Firebase config until you regenerate it.
• The track excludes the tester's country. A closed track distributes only to the countries you select for it, so a tester outside that list cannot install no matter how the invite was sent.

There is a sixth failure that looks like one of these and is not: a release sitting in review. Play runs pre-review checks before Google looks at a change, and a change held there never reaches your testers. That is a different diagnosis with a different fix, covered in pre-review checks.

Across the campaigns we analyse, the pattern in FlutterFlow projects matches the pattern elsewhere: the build pipeline is rarely the problem. The fifteen minutes of Play Console work after the build is.

After the 14 days: applying for production access

When the count is met, the application is filed in Play Console, not in FlutterFlow. You answer Google's questions about the test itself, which is where most of the writing happens, and the form is covered question by question in production access form questions.

Google then reviews the request. If it comes back asking for more testing, the two named reasons are having fewer than 12 opted-in testers and insufficient tester engagement during the period, so a technically clean test with silent testers can still be sent back. Review timelines, including what a long wait means and what it does not, are in production access review time.

Back in FlutterFlow, select I've applied so the Google Play card stops asking. If the application is refused, the reasons are almost always fixable and never require a new app record: see production access rejected.

Frequently asked questions

Does FlutterFlow need 12 testers for every app? No. The requirement applies to personal developer accounts created after 13 November 2023, and it has to be met before the account can release any app to production. Organization accounts do not run it.

Can I skip uploading the first .aab myself? No. Google's API can upload files to an app that already exists but cannot create the app, so the first file goes through Play Console once. Every build after that can come from FlutterFlow.

Can I upload the .apk instead of the .aab? No. Play accepts the bundle. FlutterFlow's .apk download exists for installing on a phone yourself, and its ceiling is lower than the bundle's.

Does sending a new version reset the 14 days? Sending an update does not reset anything by itself. What resets or pauses the count is losing opt-ins, for example testers who uninstall or opt out. That case is worked through in dropping below 12 testers.

Can I change the package name after the app is on Play? Not on the existing record. Both FlutterFlow and the stores treat it as fixed once deployed, so a new package name means a new app and a new test.

Do FlutterFlow testers have to use the Google Group? No. Email lists work in Play Console and testers on them get every version. FlutterFlow just will not display those testers in its panel, so watch the opted-in count in Play Console instead.

Do testers need to open the app every day? Google does not require daily opens. It does look at engagement when reviewing the application, which is a different standard and is explained in do testers need to open the app every day.

Sources and verification

Policy claims come from Google's Play Console help, and FlutterFlow behaviour from FlutterFlow's documentation. All pages were read in full on 6 November 2026.

• App testing requirements for new personal developer accounts — Google Play Console Help. The 12-testers, 14-days wording, the closed-test requirement, and review timing quoted above are from this page.
• Set up an open, closed, or internal test — Google Play Console Help. The fixed package name, the several-hour delay on a new test link, and the rule that internal-test opt-ins block closed-test opt-ins.
• Add to Play Console and Send to testers — the first-file rule and the draft first rollout.
• Troubleshoot phone builds and store releases — the exact card text quoted in the table.
• Add testers — Google Groups shown, email lists not shown, and the statement that FlutterFlow does not track testers or days.
• Launch checklist and Store requirements and fees — App ID sequencing, file-size ceilings.
• Google Play Store Deployment — Studio path, service account, keystore, auto-incremented build number, and the package name that cannot change after deployment.

FlutterFlow ships two products with different deployment screens, and the UI wording differs between them. Where this article quotes card text, it is the current agent-based product. Studio's flow reaches the same Play state through different labels.