Crashlytics Missing libc.so and libart.so Missing BuildId

[Samet Doksanoğlu]

Hi,
We have been using firebase crashlytics to see our android game crashes which is built in Unity Framework. We upload symbols file with firebase cli. The commands to upload symbols file are as below;
  firebase crashlytics:mappingfile:generateid --resource-file=crashlytics_id-$BUILD_NUMBER.xml
  firebase crashlytics:mappingfile:upload --app=$APP_ID --resource-file=crashlytics_id-$BUILD_NUMBER.xml  $APP_NAME-${BUILD_NUMBER}_mapping.txt
  firebase crashlytics:symbols:upload --app=$APP_ID $APP_NAME-$BUILD_NUMBER-$BUILD_NUMBER-v$BUILD_NUMBER.symbols.zip

However we could not see some crash logs which which shows "Missing BuildId" in the firebase build. I will share two crashlytics event as an example;
In these crash events, libc.so and libart.so is not seen.
- Is there anything to do from our side to be able to symbolicate this libraries(libc.so and libart.so)?
- First command that I shared (firebase crashlytics:mappingfile:generateid) creates an xml file,  and then with the second command I upload it to firebase. In the firebase cli documentation, it is not explained eloborately, but should this xml file be included in android aab bundle?

- What else can I upload to Firebase to see more transparent  crash logs?

firebase cli version: 11.13.0
firebase-crashlytics-ndk:18.3.2
firebase-crashlytics-unity:10.3.0

[Joe Spiro]

Hello Samet,

Currently we cannot symbolicate system frames like libc.so and libart.so as we don't have visibility into the symbols associated with system libraries. We're working on making this better but don't have more info for you at this time.

If symbols are missing elsewhere in the stack though, that is something we can help you to ameliorate at this time.

[Samet Doksanoğlu]

Hello Joe,

Thank you for your response. I came across a post shared by the one  of the firebase members. He mentioned that the  crashlytics mapping file should be included in aab bundle, however I just upload it to firebase. Do you think I need to add it aab bundle? If I don’t add it, does it deteriorate symbolication quality?

Thank you

[Joe Spiro]

Hello Again,

I'm currently looking further into this but please answer a couple questions.

Are you using the Firebase SDK for Unity or are you directly employing the Android SDK?

Please share where you got that particular upload command syntax/format.

Has anything in your crashes/callstacks shown up as unsymbolicated besides libc.so and libart.so? I ask, because if only libraries that cannot currently be symbolicated are missing, then everything else is working as intended and you don't need to change your current process.

That said, the current suggested way of uploading Unity symbols to Firebase is simpler. Consider testing this and implementing it if it works for you. This would likely automatically handle some of the steps you're asking about.

[Samet Doksanoğlu]

I am using Firebase SDK for Unity. Besides libc.so and libart.so it does not show app_process64 and one or two low-level library. What I am curious about is how it is handling mapping file id. Crashlytics gradle plugin creates   crashlytics_build_id.xml and crashlytics_unity_version.xml under FirebaseCrashlytics.androidlib folder but not a file related to mapping file. However I think I may need to add output of  firebase crashlytics:mappingfile:generateid --resource-file=crashlytics_id-$BUILD_NUMBER.xml under FirebaseCrashlytics.androidlib folder. Secondly when I read the link you shared (uploading Unity symbols to Firebase),  It says I need to set application android:allowNativeHeapPointerTagging="false",  it is not explained  why I need to disable it and what  its relation with crashlytics events is. Secondly, how can I be sure that disabling this feature adds some bugs in our android game?

Thank you

[Joe Spiro]

"it is not explained  why I need to disable it"

This is related to tagged pointers which are primarily used by other methods of debugging memory and allocation issues. As discussed in Android Developers > Develop > Guides ><application>, removing this is unlikely to cause issues but may make a narrow class of issues more obscure to debug without additional mechanisms for memory checking/debugging.

That said, you can combine Crashlytics with another method for memory debugging: GWP-ASan. Instructions for using the two together are mentioned in Get Android NDK crash reports.

If you are interested, try implementing the alternative upload method discussed in my previous message with some of the above enabled and see if you get at least the same amount of info.