Crashlytics plugin selects wrong applicationId - doesn't honour changes by setApplicationId()
See original GitHub issue[READ] Step 1: Are you in the right place?
Issues filed here should be about bugs in the code in this repository. If you have a general question, need help debugging, or fall into some other category use one of these other channels:
- For general technical questions, post a question on StackOverflow with the firebase tag.
- For general Firebase discussion, use the firebase-talk google group.
- For help troubleshooting your application that does not fall under one of the above categories, reach out to the personalized Firebase support channel.
[REQUIRED] Step 2: Describe your environment
- Android Studio version: 4.0 RC1
- Firebase Component: Crashlytics Gradle Plugin
- Component version: 2.1.0
[REQUIRED] Step 3: Describe the problem
My project uses a combination of flavorDimensions and buildTypes to generate 4 different apps with different app IDs. To do this, I use an “applicationVariants.all” loop to process the combination of flavors and types to decide on the applicationId to use.
The problem is that the Crashlytics plugin doesn’t appear to honour the result - it’s extracting config from google-services.json based on the default applicationId specified within the flavorDimension, rather than the dynamically configured one.
If I don’t specify an applicationId in the flavors, it appears to read the package from the AndroidManifest.xml - which also isn’t correct.
I can’t see any way to tell Crashlytics which applicationId to use.
Steps to reproduce:
See test gradle config extract below. Building “productaProdRelease” will correctly use applicationId “com.producta.app”. Building “productaNightlyRelease” will also use that same applicationId when deciding which part of google-services.json to use, even thought application will be built with applicationId “com.development-producta.app.something” as set by setApplicationId().
This results in crash reports being sent (according to the logcat console) but never actually appearing on the web site (I assume because they’re sent to one project, with the applicationId from a different one).
Relevant Code:
flavorDimensions "PRODUCT", "TARGET"
productFlavors {
producta {
dimension "PRODUCT"
applicationId "com.producta.app"
}
productb {
dimension "PRODUCT"
applicationId "com.productb.app"
}
nightly {
dimension "TARGET"
}
sprint {
dimension "TARGET"
}
prod {
dimension "TARGET"
}
}
buildTypes {
debug {
}
release {
}
penTest {
}
store {
}
}
applicationVariants.all { variant ->
def mergedFlavor = variant.mergedFlavor
if (variant.flavorName.startsWith("producta")) {
if (variant.flavorName.contains("Prod")) {
mergedFlavor.setApplicationId("com.producta.app")
} else {
mergedFlavor.setApplicationId("com.development-producta.app.something")
}
} else {
if (variant.flavorName.contains("Prod")) {
mergedFlavor.setApplicationId("com.productb.app")
} else {
mergedFlavor.setApplicationId("com.unrelated.app.something")
}
}
}
Issue Analytics
- State:
- Created 3 years ago
- Comments:18 (7 by maintainers)
Top GitHub Comments
Hello again everyone!
We believe we’ve tracked down the issue. It’s related to the dynamically-set application ID not being picked up by the Google Services Plugin. This does cause downstream effects in Crashlytics, but also in other Firebase products, as has been shown.
While we work to determine the best solution to this problem, we’ve found a simple workaround, which is to apply the Google Services Plugin after setting the application IDs in your
applicationVariants
block. So given the previous example:Try this out and let us know how it goes, and I’ll let you know when we have more details to share on this. 😃
Hi there! Just wanted to let folks know we’re aware of this issue and working on getting a fix in for it. 😃
Thanks for the report!