Google Play Closed Testing for Flutter Apps: Complete Guide 2026
How Flutter developers complete Google Play closed testing in 2026. Building your AAB, configuring Play Console, and getting 12 testers.
2 min read
In this article
Flutter developers building Android apps face the same closed testing requirement as native Android developers: 12 real testers for 14 consecutive days before production access. The Flutter-specific considerations are around building and uploading your release properly. Here is the complete guide.
Building a Flutter Release for Google Play
Flutter apps are distributed through the Android packaging system. For Google Play, you need an Android App Bundle (AAB) rather than a raw APK.
To build a release AAB from your Flutter project, run the following command in your terminal: flutter build appbundle --release
This creates a release AAB at build/app/outputs/bundle/release/app-release.aab.
Before building, ensure your AndroidManifest.xml has the correct permissions declared and your build.gradle has the correct versionCode and versionName set.
App Signing for Flutter on Google Play
Google Play requires app signing. The recommended approach is to let Google manage the signing key through Play App Signing.
When you upload your first release to Play Console, you will be prompted to enroll in Play App Signing. Accept this. It means Google holds the production signing key, which provides security benefits and enables features like split APKs.
For local testing, you can use a debug keystore. For Play Store uploads, always use a release signing configuration.
Uploading to Closed Testing
Follow the standard Play Console setup process described in the How to Set Up a Closed Testing Track guide. The steps are identical for Flutter apps - upload your AAB, configure tester groups, publish the release.
One Flutter-specific consideration: make sure your AAB meets Google's size limits. Large Flutter apps with many assets can approach the 150MB base APK limit. Use asset compression and tree-shaking (flutter build appbundle --release automatically applies tree-shaking for Dart code).
Common Flutter-Specific Issues in Closed Testing
Release mode crashes: Flutter apps sometimes behave differently in release mode versus debug mode, particularly around method channels and platform-specific code. Test your release build locally on a physical device before uploading to Play Console.
Missing permissions: Double-check your AndroidManifest.xml for all required permissions. Flutter packages sometimes require permissions that need to be added manually.
Minimum SDK version: Set your minSdkVersion appropriately in your build.gradle. Google Play's closed testing distribution settings must match. If your app requires Android 8.0, set minSdkVersion 26.
Getting 12 Testers for Your Flutter App
The tester sourcing process is identical regardless of whether your app is Flutter, native Kotlin, React Native, or any other framework. Google Play's closed testing mechanism does not care about your development stack - it cares about real testers on real devices.
TestSlot's tester pool is device-agnostic. Testers have real Android phones and install your app from the Play Store like any other app. The fact that it is built with Flutter is invisible to them and irrelevant to the verification process.
List your Flutter app on TestSlot, add TestSlot's group email to your Play Console tester group, share your opt-in URL, and start your 14-day clock.
One TestSlot-specific advantage for Flutter developers: the live dashboard lets you verify that testers are actively opening your app - useful for confirming that Flutter's hot restart does not cause issues with the installed release build.
Start your Flutter app's closed testing at testslot.io.
Need 12 testers for your closed test?
TestSlot gives you real, verified testers who keep your app installed for the full 14 days - with daily proof, a live dashboard, and a money-back guarantee.

