Search for a command to run...
No comments yet. Be the first to comment.
As Flutter developers, we love the efficiency of writing code once and deploying it everywhere. But when it comes to the very final step of launching or updating an app, generating App Store and Play
Last month, I set myself a new challenge: to build and release a small app from scratch within a month. This decision came after a realization I had while working on my previous project. That project had so many uncertainties and things left to do th...
Using Flutter's CustomPaint to create futuristic looking widgets.
Last year, I wrote two articles about theming in Flutter, sharing my frustrations with ThemeData (part 1 & part 2). While ThemeData is powerful, its extensive properties can be overwhelming, especially when many of them are rarely used. After experim...
On this page
If you're looking for a streamlined way to distribute your Android test builds using Firebase App Distribution (FAD) with the modern Android App Bundle (.aab) format, you might want to pause.
While the promise of using AABs via FAD—leveraging the Google Play Console's infrastructure—is appealing, the actual setup and testing experience is often frustrating, counter-intuitive, and requires far more configuration than anticipated.
In my opinion, the increased complexity and hidden obstacles make uploading standard APKs a far superior and faster way to start testing.
Here is a breakdown of the three major hurdles I encountered, followed by a guide on how to get it working and my final verdict.
The official documentation suggests you only need to have your app published on "at least one track" (like the Internal Test Track) to link Firebase and the Google Play Console. This proved to be insufficient.
Despite having multiple builds successfully running on the Internal Test Track, I constantly ran into the infamous error:
"1 linked app is not on a published track in Google Play"
This error persists unless you have completed a significant portion of the tedious Google Play listing configuration, including details that seem irrelevant for private test distribution (e.g., store graphics, privacy policy links, target audience, content rating questionnaires).
When you link Firebase to the Google Play Console, the expectation is that Play will handle the generation of APKs from the AAB and sign them using the same key as your production app (the Upload Key or the Play App Signing Key).
This is crucial for features dependent on the app's signing certificate, such as:
Google Sign-In
Google Maps API
In-App Purchases (IAP) (Often tied to your Play Console configuration)
Upon the first AAB upload to FAD, Firebase creates its own temporary signing certificate to generate the necessary APKs for App Distribution testers.
The Problem: This certificate is different from your production or developer keys. Consequently, any critical service (like Google Sign-In) configured to accept only your legitimate app signing fingerprint will immediately fail in the test build distributed via FAD.
The Workaround: To make Google services work, you would have to register the temporary Firebase signing certificate fingerprint with Google Cloud Console, which is tedious and undermines the goal of seamless testing.
Contrast: If you upload a standard APK, you can sign it yourself using your true production/developer key (provided you don't use Google Play App Signing), ensuring all your dependent services work out of the box.
After finally conquering the setup and signing issues, the final hurdle was the installation experience for the tester using the recommended App Tester app.
When a non-technical tester attempts to install the app via the FAD App Tester, they are met with a jarring and complex installation process:
They are prompted to go into their phone's Google Play settings.
They must press a specific item 7 times to activate Developer Mode.
They must enable a specific security check to allow the installation of the test app.
This kind of process is acceptable for a developer installing an app via Android Studio, but it is an absolute nightmare for non-technical internal stakeholders, marketers, or management testing a build.
Firebase App Distribution is an excellent tool, but the integration with Android App Bundles is flawed and requires too much upfront investment in Play Console configuration and forces the use of a non-production signing key.
| Feature | AAB via Firebase App Distribution | Standard APK via Firebase App Distribution |
| Setup Barrier | HIGH (Requires extensive Play Console config) | LOW (Uploads instantly) |
| Signing Key | New/Unique Firebase Key (Breaks services) | Your Chosen Key (Services work) |
| Tester UX | POOR (Requires Developer Mode activation) | GOOD (Simple installation prompt) |
| Flexibility | LOW | HIGH |
If your primary goal is fast, reliable, and flexible internal distribution for testers and stakeholders:
Skip the AAB integration with FAD and upload your locally signed APK files directly to Firebase App Distribution.
This approach allows you to:
Use your actual developer or production signing key.
Avoid the onerous Google Play Console configuration requirements.
Provide a simple, non-technical installation experience for your testers.
Hopefully, this information saves fellow developers the many hours of frustration I endured.