Firebase App Distribution & Android: a guide pt. 2

The third day’s post of Mercari Advent Calendar 2019 is brought to you by @panini from the US@Tokyo Android team.

Goodbye Fabric, Hello Firebase 👋

This is part 2 in our 2 part series looking at how to migrate from Fabric Beta to Firebase App Distribution. Part one is available here.

Uploading build

We’re finally on the home stretch! Time to upload some builds 💪

There are a couple of ways we can do this – either directly calling the Firebase CLI, or by using Fastlane.

Using Firebase CLI

If we are using the Firebase CLI, the command we want to call is

$> firebase appdistribution:distribute <path/to/apk> 
--app <Firebase app id> 
--group <tester group> 
--release-notes <release notes>

There is one required flag, and several optional flags that you can supply to make the upload easier:

This is the Firebase project app id – this can be found in the settings section of your Firebase project.

This is the group that we created in the Firebase setup step – by specifying this group, our uploaded APK will be automatically distributed to these testers.

As implied by the flag name, this is for the release notes for the distributed APK. You can also use the --release-notes-file flag to pass a file which includes the release notes instead.

After building our APK, by just calling this function and passing the required flags, the APK will be uploaded and automatically released to anyone in our tester group! 🎉

Using Fastlane – optional

Uploading via Fastlane is similar to using the Firebase CLI, however there is a task provided by the plugin which makes it a lot easier. By creating a lane similar to the following, we can perform the same tasks as the Firebase CLI

desc "Submit a new build to Firebase App Distribution"
lane :deploy_firebase_app_distribution do |options|
apk = File.join(<path/to/apk>, "<apk name>.apk")
message = create_release_note # private lane to generate release notes
apk_path: apk,
firebase_cli_path: File.join(PROJECT_ROOT, 'node_modules/firebase-tools/lib/bin/firebase.js'), # if installed through NPM
release_notes: message,
groups: '<tester group name>'

we can then run this by calling fastlane deploy_firebase_app_distribution 🚀

Distributing to testers

Finally, its time to distribute our APK to our testers! The way to do this is to generate an invitation link, and give that to your testers. Once they have signed up with the invitation link, any new builds for the group in the invitation link will be automatically distributed to them ✨


Phew! Finally we’ve uploaded our build, and distributed it to our testers! Next, lets go through some of the gotchas that I noticed while doing the migration.

I can’t see any builds!?

This was a question I got fairly early on from our testers. Firebase App Distribution – like Fabric Beta will only add a tester to builds uploaded after they registered. This means that after you register testers, you should either redistribute a build, or alternatively you can manually add testers to previously distributed builds from the Firebase console.

Builds fail to upload!?

While I believe (hope!) this is due to Firebase App Distribution still being in beta, occasionally uploads will fail with either a 404 Entity Not Found, or a 500 Internal Server Error response. While this is a little frustrating to deal with, usually reattempting the upload will work successfully.

Logging in on QA devices is difficult?!

When creating the invitation link, there is an option to restrict the link to only email addresses of a certain domain. This is good in theory, however for QA devices that may not be logged in with company accounts (to ensure they don’t have access to anything they shouldn’t), it makes the login process difficult. For this, its better to create a separate link and group just for QA devices, and provide that link to your testers.


Firebase App Distribution is fairly easy to set up, once you have all the prerequisites in place. The fact that it is integrated with Firebase means you can use interesting things like Big Query with your crashlytics logs that you get back from debug/production builds, meaning that it should be easier to nail down the causes of those tricky bugs. And while the upload service is a little unstable at the moment, I believe this is just down to the product still being in beta.

Tomorrow’s blog – the 4th in the Advent Calendar will be written by @siroken3. Please look forward to it! 😸

  • Twitter
  • Facebook
  • linkedin
  • このエントリーをはてなブックマークに追加