Publish a Flutter App on Google Play: The Testing Step

Here's the path from your next click to a Flutter build sitting on a closed testing track. First you sign the app, then you build an app bundle, then you upload it to a closed track in Play Console and invite testers. Production comes after the 14 days, not before.

PeerPlay itself is a Flutter and Firebase app, so this is the route I know best. Most of it is standard Android publishing. A few steps are specific to Flutter, and those are the ones that trip people up.

Fix the package name before anything else
A new Flutter project starts with an application ID like com.example.your_app. Play Console won't accept a package name that starts with com.example, and once you upload a build with a given package name, that name belongs to the app for good. You can't rename it later.

Change the applicationId in your android/app build file to something you own, such as com.yourname.appname, before the first upload. If you also changed the namespace or the Kotlin package folder, run the app once on a device to make sure nothing broke.

Sign the release build
Debug builds are signed with a debug key that Play Console rejects. You need an upload key. Create one with the keytool command that ships with the JDK, keep the .jks file somewhere outside the project, and back it up. Losing it is fixable through Play Console support, but it's a hassle you don't want.

The Flutter docs show the usual setup: a key.properties file with the store path and passwords, and a signingConfigs block in the android/app build file that reads it for the release build type. Keep key.properties out of git. On new apps Google manages the real app signing key through Play App Signing, so the key on your machine is only used to prove the uploads come from you.

Build the app bundle and set the version
Google Play wants an Android App Bundle, not an APK. Run flutter build appbundle and the output lands in build/app/outputs/bundle/release as app-release.aab.

Look at the version line in pubspec.yaml, something like 1.0.0+1. The part before the plus is the version name users see. The number after it becomes the version code, and Play Console rejects any upload whose version code it has already seen. Bump that number every time, even for a tiny fix during the test. It's the most common reason a second upload fails.

Before you upload, run the release build on a real phone with flutter run --release. Release builds strip debug tooling and can behave differently, especially around code shrinking and plugins that need extra rules.

Getting the build onto a closed track
In Play Console, open Testing, then Closed testing, and create a release on the track. Upload app-release.aab, add release notes and save. Then fill in whatever the dashboard still flags as missing: store listing, content rating, data safety, target audience and the app access details if your app has a login. Google reviews the first release, so incomplete forms just delay you.

On the Testers tab, attach an email list or Google Group and copy the opt-in link. Testers have to open that link and accept the invite with the same Google account they use in the Play Store. Adding them to a list alone doesn't count them.

If you want a sanity check first, the internal testing track is useful for making sure the bundle installs and starts properly on a few of your own devices. It doesn't count toward the closed testing requirement, so don't wait on it long.

Flutter details that matter during the 14 days
You can ship updates while the test is running. Upload a new bundle with a higher build number to the same closed track and testers get it as a normal update. That doesn't remove anyone from the test.

If you use Firebase, add the SHA-1 and SHA-256 fingerprints of the Play App Signing key from Play Console to your Firebase project, not only your local debug and upload keys. Google sign-in that works on your machine and fails for every tester is very often this.

And make sure testers actually open the app. A tester who installs and never launches it tells you nothing, and the production application asks what you learned from the test. That's the gap PeerPlay was built around: testers are swapped between developers and tracked for real sessions over the 14 days, not just installs.