Crashlytics: Impossible to set custom appIdentifiers instead of using app package name

Fabric Crashlytics had a way of setting appIdentifier for your builds that doesn’t necessarily need to follow the package name. Documentation here

Example:

final Fabric.Builder builder = new Fabric.Builder(this);
if (isAlpha) {
	builder.appIdentifier("com.example.alpha");
} else if (isBeta) {
	builder.appIdentifier("com.example.beta");
} else if (isCI) {
	builder.appIdentifier("com.example.ci");
} else {
	builder.appIdentifier("com.example");
}

The current firebase-crashlytics sdk doesn’t allow this type of configuration and it hardcodes the appIdentifier to use the package name, which is not always the case.

In our current implementation we have different appIdentifier based on different open/closed tracks in Play Store for alpha/beta users as well as CI builds, and all share the same package name that is not possible to modify at this point.

If we continue with the migration from Fabric sdk to Firebase sdk we will start receiving all the crash reports for all of our configurations under the same project, making unviable filtering and identifying crashes/regressions per build in a proper manner.

[REQUIRED] Step 2: Describe your environment

• Android Studio version: 4.0
• Firebase Component: Crashlytics
• Component version: 17.1.0

[REQUIRED] Step 3: Describe the problem

Steps to reproduce:

Follow migration guide https://firebase.google.com/docs/crashlytics/upgrade-sdk?platform=android There is no option to migrate custom appIdentifier to the new SDK. Source code shows appIdentifier is hardcoded to use package name, making impossible to identify different app types of the same package name

[ashwinraghav]

That does make sense.

While there are more straightforward workarounds for other Firebase products, crashlytics, analytics and a few others that have implicit behavior on app start are a bit harder to work with for your scenario. While we continue triaging a way to provide a better API that would help your use case (#66), here’s a suggestion.

If you setup (say) 3 different Firebase projects (tumblr_prod, tumblr_stage, tumblr_ci), and in each of these projects, you create an app that has your real package name “com.tumblr.readerapp”. This would give you 3 different google-services.json files, each one containing information that you need to operate three different builds of your app.

In a pre processing stage, it should be possible for you to wire in the right version of the google-services.json file into your app directory structure, depending on the build type.

While inconvenient, that should help circumvent the API limitations you are facing.

[obsantos]

@ashwinraghav thanks for following up! In our case flavors don’t help us since our package name is the same for alpha/beta/production flavours/build types.

Sadly we can’t change the package name at this point because it’s how our app (Tumblr) its been setup in Play Store since years ago.

Fabric allowed us to set the identifier we wanted independent form the package name, giving us the flexibility of creating different projects in Firebase for a given build (CI, internal testing, etc…) without having to maintain multiple flavors for those.

Some of the scenarios we can find a workaround using flavors, but for our alpha/beta tracks we are blocked by the impossibility of changing package name in Play Store. Migrating would mean having reports of the 3 build types (alpha/beta/prod) in the same project, making it harder to find regressions in stability, etc…

I understand following the package name defined by the flavor is a good default value for the app identifier, but having the flexibility of defining a custom one would definitely help apps that have been around for a long time (Tumblr was published in 2010 😅) and have some “legacy” configurations that are somehow hard to modify at this point.