Mapping files: why Crashlytics says unknown after a perfectly ordinary R8 run

R8 is not the villain

R8 shrinking and obfuscation are ordinary for a Play release. The failure is operational: the mapping file for a given version code was overwritten, never archived, or uploaded to the wrong crash reporter project. Play Console can deobfuscate some Java crashes if you upload the mapping there. Many teams upload it once, then forget after a flavour split.

We have opened audits where four version codes were noisy and only one mapping existed. The finding pack then has a blunt section: these three version codes remain unnamed. That is still useful. It tells you the archive process broke.

Flavours and the quiet second mapping

A store flavour and a white-label flavour can share an application ID suffix pattern that confuses people, or they can be separate application IDs that each need their own mapping. If your CI job publishes mapping.txt from the last flavour that built, the first flavour’s crashes will look like a different app’s leftovers.

Send every mapping that matches the version codes in the vitals window. If you are unsure, send too many. We will match them by version code, not by the filename someone chose at 1 a.m.

Native is a second archive

Java mappings do not symbolicate .so crashes. If you ship native libraries, keep the unstripped copies or Breakpad/LLDB symbols for that exact build. A crash stability audit that receives only mapping.txt will still cluster native faults by the .so name and build-id when present, but it will not name your C++ functions.

Request an audit briefing if this is the cluster on your desk this week.