Using Android builtin resources will break the BuildId and crash the App

[seyedjafariy]

Step 1: Environment

• Android Studio version: 4.0.1 stable
• Firebase Component: Crashlytics
• Component version: 17.2.1

Step 2: The problem

After adding the Crashlytics library to our App. the App kept crashing on startup saying the BuildID is missing please follow the integration process.
But We followed those steps a million times and on different machines and still no luck.

At the end, after debugging the Crashlytics SDK I found the problem is getResourcesIdentifier(context, "com.crashlytics.android.build_id", "string"); returning 0.

After digging a lot more it turns out the reason for this null return, is this line in the Application tag of android-manifest.xml:
android:icon="@android:drawable/ic_menu_today"

So by removing this line or changing the icon everything was fixed and normal again

Steps to reproduce:

So just add this android:icon="@android:drawable/ic_menu_today" icon as your application icon and remove other round Icon if exists.

[kevinkokomani]

Hmm, do you happen to have a reproduction of this handy that you could upload and send over a link to? We would love to be able to test this out ourselves, looks like a strange error. Alternatively, could you specify a bit more the steps to reproduce this -- are you basically just integrating Crashlytics in a blank app, and then adding the android:icon="@android:drawable/ic_menu_today" as the application icon to get this to occur?

[seyedjafariy]

Thanks for the prompt response.
Yeah, the repro is that easy (I tried on one or two projects only honestly).
please check this sample project as a sample for this bug. (I have committed my google-services.json to allow complete pull)

https://github.com/worldsnas/FirebaseCrash

Please note that if I add a round icon the issue will be resolved. and as I mentioned earlier the issue exists because android does not return an id for the buildId resource and thus Crashlytics can not find the resource

[mrichards]

The issue is due to the way Crashlytics identifies the package name to be used when retrieving string resources, in a way that supports the old --rename-manifest-package aapt option. It assumes that you're app has either an app-specific icon OR the default system one. It appears to have not been tested against arbitrary built in resources. (Check out the code.)

We'll need to consider if it is worth dropping support for that option, though in the meantime we can make a fix that at least avoids attempting to use "android" as the package name, which is what is happening in your case.

[seyedjafariy]

Thanks for escalating the issue @mrichards.
Do you mind explaining why you just don't use context.getPacakgeName()? what would this function return if we have that flag --rename-manifest-package enabled?
please

[mrichards]

@worldsnas The resource packages aren't renamed when using --rename-manifest-package, so the result of context.getPackageName() won't match. To get around this, Crashlytics looks at a known resource (the launcher icon) and assumes that its package name matches the strings resources' package name. As you discovered, that assumption can break when the app is not using a custom launcher icon.

The accepted answer to this SO post, and the linked Google Forum thread, have some additional information.

[mrichards]

The fix will go live with our next release (date & version # TBD).