Firebase App Distribution & Android: A Guide

Goodbye Fabric, Hello Firebase 👋

For those of you using Fabric Crashlytics for crash reporting, or Fabric Beta for distributing builds to testers, Fabric will be deprecated on March 31, 2020. That means there is just around 1 quarter before we need to migrate our apps to Firebase. 🙀

Thankfully, the migration to Firebase App Distribution is fairly painless and, if everything goes to plan, should take less than an hour to complete. 🎉

Prerequisites

To start, you will need to have write access to a Firebase Project.

Next, while optional, I would recommend setting up Fastlane which is incredibly useful for automating app tasks. Installing Fastlane is beyond the scope of this blog post, but there are many good articles out there on how to do this.

Finally, I would also recommend having a CI system from which to deploy builds — this will mean that builds are always built inside the same environment, and ensure that the number of human errors caused when creating a build are reduced. This step is also outside the scope of this blog post, but I would recommend either Bitrise or CircleCI as good options for mobile applications.

Setting up

Now that you’ve reviewed the prerequisites, let’s get on to the meat of migrating to Firebase App Distribution! There are a few necessary tasks, which are explained below.

Firebase 🔥

First thing first: You will need to set up the Firebase CLI. As mentioned in the official documentation, the easiest way to do this is to install it through NPM.
If you are using NPM for something else in your app (for example, ReactNative), then you can simply add "firebase-tools":"<latest version>" to your dependencies block and install the dependency through your favorite method.

Next, you will need to login to the Firebase CLI to give the tool access to your Firebase project. To do this, you can simply run the following command from the command line:

$> firebase login

The tool will prompt you to login to the Google account that has access to the Firebase project you wish to access — just follow the steps on-screen and it should set up correctly.

To test the setup, you can call the following command, which will list all available Firebase projects if set up correctly:

$> firebase list

Optional: CI login

If you are planning on uploading builds from a CI server, then you will need to generate a refresh token for the CI server to use. This can simply be done by calling the following command:

$> firebase login:ci

Like the firebase login command, this will ask you to login to a Google account that has access to the Firebase project you wish to use; once you have finished the login, it will print out a refresh token. You should use this refresh token whenever calling Firebase commands from CI, so I recommend storing this in your CI setup as an environment secret. Note that anyone can access the Firebase project with this token, so be sure to keep it secret.

If you name the variable that holds the token FIREBASE_TOKEN, then the tool should automatically pick it up. 💪

Setting up Tester groups

Finally, to finish your Firebase setup, you will want to create a group of testers to whom your app is distributed. This can be done from the Firebase console, on the App Distribution page.

Firebase App Distribution — Testers & Groups

From here, you can create a new group by clicking the Add Group button and following the steps. Make sure you keep this group name somewhere as we will require it later on in the upload process.

Fastlane 🚀 (optional)

If you are using Fastlane in your app distribution pipeline, you’re in luck! There is a Fastlane plugin designed to work with the Firebase CLI that will do much of the heavy lifting for you. By calling the following command, you can add the Firebase app distribution plugin to your Fastlane setup:

$> fastlane add_plugin firebase_app_distribution

Next, you need to set up an environment variable for our app ID. The easiest way I found to do this was to create an .env file within your Fastlane directory. If you have multiple environments (e.g. for debug or release), you can specify that in the naming of your .env file:

fastlane/.env.default # the default environment
FIREBASEAPPDISTRO_APP=<debug Firebase app id>

fastlane/.env.release # release environment
FIREBASEAPPDISTRO_APP=<release Firebase app id>

Then, when driving a Fastlane lane, you can supply the--env release flag to use the release environment.

Uploading your build

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

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

Using Firebase CLI

If you are using the Firebase CLI, the command you 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 (--app), and several optional flags that you can supply to make the upload easier:

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

--group
This is the group that you created in the Firebase setup step — by specifying this group, your uploaded APK will be automatically distributed to these testers.

--release-notes
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 your APK, by just calling this function and passing the required flags, the APK will be uploaded and automatically released to anyone in your 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, you 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
 firebase_app_distribution(
 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>’
 )
end

You can then run this by calling the following command:

fastlane deploy_firebase_app_distribution

🚀

Distributing to testers

Finally, it’s time to distribute your APK to your testers! To do this, generate an invitation link and provide it to your testers. Once they have signed up with the invitation link, any new builds for that corresponding group will be automatically distributed to them. ✨

Gotchas

Phew! Finally, you’ve uploaded your build and distributed it to your testers! Next, let’s 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 that were 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 are failing 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, reattempting the upload will usually 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 scenario, it’s better to create a separate group and corresponding link just for QA devices and provide that link to your testers.

Closing

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 (again, hope!) that this is just due to the product still being in beta.

Thanks for reading — I hope this helps smooth your transition to Firebase. If you’re looking for new opportunities, come contribute to what we’re doing at Mercari!