Skip to main content

Command Palette

Search for a command to run...

🛑 Warning: The Hidden Costs of Using Firebase App Distribution with Android App Bundles (AAB)

Updated
•4 min read
🛑 Warning: The Hidden Costs of Using Firebase App Distribution with Android App Bundles (AAB)

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.


1. The Setup: A Deceptively High Barrier to Entry

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.

The Reality: You Need a Near-Complete Play Store Listing

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).

  • The Cost: The "quick start" promised by FAD and AABs forces you to complete a substantial part of your production configuration just to distribute a test build. The threshold for simply beginning internal testing becomes unnecessarily high.

2. The Critical Misunderstanding: Signing and Service Keys

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)

The Reality: Firebase Generates Its Own Signing Certificate

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.


3. The End-User Experience: An Unacceptable Installation Flow

After finally conquering the setup and signing issues, the final hurdle was the installation experience for the tester using the recommended App Tester app.

The Reality: Developer Mode for Everyone

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:

  1. They are prompted to go into their phone's Google Play settings.

  2. They must press a specific item 7 times to activate Developer Mode.

  3. 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.

  • The Cost: This significantly increases friction and requires extensive hand-holding, defeating the purpose of a simple distribution tool.

đź’ˇ Final Verdict and Suggestion

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.

FeatureAAB via Firebase App DistributionStandard APK via Firebase App Distribution
Setup BarrierHIGH (Requires extensive Play Console config)LOW (Uploads instantly)
Signing KeyNew/Unique Firebase Key (Breaks services)Your Chosen Key (Services work)
Tester UXPOOR (Requires Developer Mode activation)GOOD (Simple installation prompt)
FlexibilityLOWHIGH

My Suggestion: Upload Signed APKs

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:

  1. Use your actual developer or production signing key.

  2. Avoid the onerous Google Play Console configuration requirements.

  3. Provide a simple, non-technical installation experience for your testers.

Hopefully, this information saves fellow developers the many hours of frustration I endured.