How to upload a mapping file to Firebase Crashlytics?

Question

In the old Crash reporting - there is easy way to upload. i didn't find it in the Crashlytics section

Solution 1

UPDATE: Firebase update their docs: see here

There is no need anymore to manually upload mapping file.

1 - To preserve the info Crashlytics needs for readable crash reports, add the following lines to your config file:

-keepattributes *Annotation*
-keepattributes SourceFile,LineNumberTable
-keep public class * extends java.lang.Exception

2 - To let Crashlytics automatically upload the ProGuard or DexGuard mapping file, remove this line from the config file (app/proguard-rules.pro):

-printmapping mapping.txt

For faster builds with ProGuard, exclude Crashlytics. Add the following lines to your config file:

-keep class com.crashlytics.** { *; }
-dontwarn com.crashlytics.**

Solution 2

Mike from Firebase here. Crashlytics in Firebase does not offer a way to upload mapping files outside of the build flow. I'm personally curious, did you use the manual upload frequently?

Solution 3

If you have followed the indications to enable the automatic upload then build the app and you still see the stack traces obfuscated in Firebase you should check the log files:

On Linux / Windows: /.crashlytics/com.crashlytics.tools/crashlytics.log
On Mac: ~/Library/Caches/com.crashlytics/com.crashlytics.tools/crashlytics.log

Look for the latest entry with: Uploading deobfuscation file

And try to find the result of the operation like: Deobfuscation file(s) uploaded or Crashlytics had a problem uploading the deobs file and you will get some hints about the cause.

Solution 4

Set the firebaseCrashlytics.enableMappingFileUpload Gradle extension property to true in your app-level build.gradle file.

// To enable Crashlytics mapping file upload for specific product flavors:
  flavorDimensions "environment"
  productFlavors {
    staging {
      dimension "environment"
      ...
      firebaseCrashlytics {
        mappingFileUploadEnabled false
      }
    }
    prod {
      dimension "environment"
      ...
      firebaseCrashlytics {
        mappingFileUploadEnabled true
      }
    }
  }

for more details visit Click here

View more solutions

Comments

[itzhar]

Tnx Mike. Yes I use it a lot

[Mike Bonnell]

@itzhar would you be open to chatting about this more? Would love to understand the need for the manual upload outside of a build flow.

[Michael Sotnikov]

I have proguard config file updated with mentioned rules. I see :app:crashlyticsStoreDeobsRelease :app:crashlyticsUploadDeobsRelease during the build. But all callstacks in firebase ui are obfuscated.

[Michael Sotnikov]

@MikeBonnell, when it doesn't work as expected it's much more difficult to understand what's going wrong. Since there is no any idnication that mapping was uploaded - you don't know if everything is good - you need to get first crash/exception to check it. It's always better to have some control in own hands and have ability to fix it after if needed.

[Mike Bonnell]

Thanks, I'll chat with the team about making it easier to look into the build tooling logs that show whether or not the uploads were successful or not.

[Vladimir Berezkin]

@MikeBonnell, our android app is written in Scala and we use sbt for building, so we are interesting in upload mapping.txt outside standard gradle build flow.

[easycheese]

Actually you should NOT use -keep class com.crashlytics.** { ; } -dontwarn com.crashlytics.* per firebase.google.com/docs/crashlytics/get-deobfuscated-report‌​s

[q126y]

-printmapping mapping.txt It should be removed from which config file?

[darnmason]

@MikeBonnell +1 on getting better visibility of what Crashlytics is doing here, it's supposed to just work but so many of us are completely stumped when it doesn't. Question re the mapping.txt file, the docs say to remove -printmapping mapping.txt so that the file isn't generated and Crashlytics can do its thing. I have never had that line in my pro file but mapping.txt is still generated and I have never seen deobfuscated crash reports. Any insight on this quirk? Cheers

[Mike Bonnell]

There could be a variety of things happening @darnmason. If you want to look at logs, here's where they are, you just have to parse through them. On Linux / Windows: ~/.crashlytics/com.crashlytics.tools/crashlytics.log On Mac: ~/Library/Caches/com.crashlytics/com.crashlytics.tools/crash‌​lytics.log

[darnmason]

Hmm I'm not seeing anything Crashlytics related in the Caches dir on Mac, a search for those dirs and file name also turned up blank, this was straight after running gradle assembleRelease

[Mike Bonnell]

Sounds like something else is going on then. I'd recommend email support(at)fabric(dot)io with a link to this thread, and your app's build.gradle.

[jayeffkay]

What if the prod build is being done by a machine with restricted internet access? Is there any ports or such that should be opened/configured?

[Mike Bonnell]

Whitelist *.fabric.io and *.crashlytics.com on ports 80 and 443.

[HexAndBugs]

I just had Crashlytics report a crash and that was the first I knew the deobs file had failed to upload. On checking the crashlytics logs I now see Crashlytics had a problem uploading the deobs file. I re-ran the build and it uploaded OK this time, but it's a shame it fails in a non-obvious way and there's no way to manually upload. The existing crash isn't deobfuscated even though the re-run build has now uploaded it OK. I guess I just have to manually run retrace for this existing crash. In future I suppose I should tail the crashlytics log to make sure the upload works.

[Mike Bonnell]

Thanks for the feedback, will share it with the team.

[alienjazzcat]

I don't see an answer regarding the removal -printmapping mapping.txt @MikeBonnell We're building and deploying APK to Google Play from a jenkins/docker pipeline. We don't have any printmapping in our rules (custom or the default android), yet its created, and we archive it within Jenkins, but its NOT uploading to Crashlytics. Otherwise, the Triple-T plugin appears to be pushing it to Google Play console..

[alienjazzcat]

See this issue. mapping.txt is generated automatically.. printmapping has gone through a stage, at least, where its not honored. This doesn't reconcile well with the advice to remove the rule so that the plugin will upload it automatically

[Mark Pazon]

@q126y -printmapping <filename> can be found in app/proguard-rules.pro

[android developer]

@MikeBonnell I don't see -printmapping mapping.txt anywhere, and still I've noticed obfuscated stuff of my app on crashes, on Firebase Crashlytics. How come? Also mapping.txt is generated anyway, so I actually upload it to Play Console website.

[Mike Bonnell]

There are a variety of reasons, if you're hitting this after going through the changes and answers here, best to contact Firebase support.

[SteelBytes]

this is not good. Google Play lets me upload the mapping. I will not use -keep linenumbers etc in production code.

[user3690202]

@MikeBonnell It would be nice to have readable crash reports, just like we used to have on the old Firebase crash reporting system. You know, to make debugging actually possible, and stuff.

[Mike Bonnell]

Not at all, ProGuard and DexGuard are both supported when the mapping file is uploaded at build.

[Anigif]

@MikeBonnell I landed up here because I think my stacktrace isn't correct in my app, so I was wondering if it was possible to upload it manually. I'm curious to hear how Crashlytics maps the auto-uploaded mapping.txt file with the installed version. If it's based on the version string, it might fail a lot of times for me, unfortunately..

[Mike Bonnell]

Hey @Anigif the Gradle plugin generates a unique identifier so that our backend can identify your builds. This identifier is used to deobfuscate crashes and distribute the correct versions of your beta test builds. The identifier will be added to your res/values and looks like: <string name="com.crashlytics.android.build_id">RANDOM_UUID</string> Reference: docs.fabric.io/android/crashlytics/… The version string doesn't matter.

[Carsten Hagemann]

@MikeBonnell I don't see the need for Google to get notified every time I run a (release) build.

[Mike Bonnell]

@CarstenHagemann Sorry, I'm not following what you're saying. When a build happens, we generate a unique id in order to map back to the correct mapping file uploaded with that build.

[Carsten Hagemann]

@MikeBonnell This sentence "Crashlytics automatically uploads the mapping files for reach of your build variants." (source docs.fabric.io/android/crashlytics/dex-and-proguard.html) indicates to me that the mapping file is automatically uploaded every time I run a build. I don't think Google needs to know when and how often I run a build. Please correct me if my understanding is wrong. Thanks!

[Mike Bonnell]

If you want our service to de-obfuscate your stack traces, then we need to have the mapping file for the build. If you don't want to upload a mapping file for each build, you can disable it - docs.fabric.io/android/crashlytics/… and docs.fabric.io/android/crashlytics/…

[manfcas]

How do I upload a mapping file on both Firebase Crashlytics and the Play Console? If I remove -printmapping mapping.txt to automatically upload it on Firebase, the file is not generated and I can't manually upload it on the Play Console.

[Gillis Haasnoot]

I am unable to get it to work. I don't know how to find out what goes wrong. But the code remain obfuscated in the firebase console. I just want to upload my mapping.txt. Is there a way to manually to that?

[Mike Bonnell]

There is not a manual upload at the moment. You could take a look at the build.log output to try and diagnose the issue. Also, see this issue: stackoverflow.com/questions/53420776/…

[Mahdi]

My problem is i add all these line to proguard rules, most crashes show normally but some crashes show obfuscated.

[Benjamin Bisinger]

Won't -keepattributes SourceFile somehow defeat the purpose of obfuscation?

[babay]

We have automated build after every commit. So, mapping files are uploaded to firebase after every commit. It would be nice to control, when to upload mappings and when not.

[FindOutIslamNow]

I cannot understand that. If automatically uploading every time I build, then mapping will be different, right? (e.g. after publishing app, I changed code again so my new uploaded mapping will work with previousely production code?)

[Juan Franco]

The mapping file is generated and stored here (Windows): C:\Users\<username>\.crashlytics\com.crashlytics.tools\app-<‌​id>\deobs

[Juan Franco]

Looks like every build has a unique id that is used to match the code with the obfuscation file. I found that id on the .meta files.

[Helen Hakobyan]

I did everything according to this: firebase.google.com/docs/crashlytics/… I use Android Studio's Build -> Generate Signed APK. I can see in the logs here (~/Library/Caches/com.crashlytics/com.crashlytics.tools/cras‌​hlytics.log) that the deobfuscation file was uploaded sucessfully. And, still my crashes in Firebase are obfuscated. Any ideas why?

[Wayne]

Recently Firebase Crashlytics haven't uploaded my mapping file anymore. Not sure why but if I can upload mapping file myself it will be ok. If Google Play supports this feature then why FC doesnt't?

[Saeed Arianmanesh]

last paragraph for faster builds with ProGuard in firbase docs is different: -keep class com.google.firebase.crashlytics.** { ; } -dontwarn com.google.firebase.crashlytics.* link: firebase.google.com/docs/crashlytics/…

[faraday]

@MikeBonnell As you see from Juan Franco's answer above, linking the upload of mapping.txt to build process makes the process so hidden that developer is not in the loop anymore to "retry the upload properly". If a connection error occurs during the automatic upload, it's logged but Android Studio doesn't make it explicit for the developer. Without such a screen to intervene embedded in Android Studio, Firebase console (web) is always a better way if it offers manual upload option (after we release to Play Store).

[Arbaz.in]

still getting the same error I follow this linkplease help me for same

[Lena Bru]

@MikeBonnell please add option to specify where the google-services.json file is. It is very frustrating to need to create folders that only contain the google-services.json file. Or allow me to manually upload the mappings. I do not want to depend on the crashlytics plugin for gradle

[Adam Burley]

@BenjaminBisinger yes. you can verify this with APKTool or similar disassembler tools, look in the top of any supposedly "obfuscated" smali file, and it will contain the original source file name. to avoid this, you need to add -renamesourcefileattribute SourceFile to your proguard configuration. Crashlytics will still upload your mapping file and in fact it still gets the original source file name, but it's not stored in the APK

[hiddeneyes02]

Google, please just use mapping file uploaded to PlayStore to deobfuscate crash logs, simple and easy.

[mbwasi]

Any idea how to check these logs on CI? CIrcleCI in particular.

[MattMatt]

I thought I recognised that username, how random! (I swear I'm not stalking you @mbwasi! 😂) I was just debugging a log with obfuscated trace from a Bitrise deployment and found an issue on GH. It seems that it occurs when the SDK-created task :uploadCrashlyticsMappingFileRelease fails, so you could look for that in the logs to confirm if that's working on CI. Uploading the file manually seems to be a missing feature in Firebase Crashlytics at the moment, as it's still open as of this week: 😖 github.com/firebase/firebase-android-sdk/issues/…

[htafoya]

YES, it is very important on closed CI Servers with no access to Internet. Gradle dependencies are retrieved from local artifactories but the mapping cannot be uploaded automatically.

[htafoya]

Also, the firebase keys are injected post build time, so we must disable the automatic upload because at that moment the app code won't even have the firebase project info to send the mapping.