配置后Firebase Crashlytics日志仍显示混淆名 无法查看原始文件名

• 确认mapping文件实际上传状态
  配置mappingFileUploadEnabled true不等于上传一定成功，重点核对两个点：
  1. 该配置必须放在实际打包的构建变体（如release）作用域下，不要只配置在debug构建类型中
  2. 打包时查看构建日志，筛选Crashlytics相关输出，确认存在mapping文件上传成功的记录。如果出现网络异常、Firebase AppID不匹配、Google Services配置缺失等报错，先修复对应问题再重新打包，确保mapping成功上传。
• 补全混淆规则
  你当前的规则存在明显缺失，既会影响Crashlytics反混淆能力，也会直接导致Fragment被混淆后出现运行时实例化失败的问题，在proguard-rules.pro中补充以下规则：

# 保留文件名、行号、注解信息，供Crashlytics反混淆使用
-keepattributes SourceFile,LineNumberTable
-keepattributes *Annotation*

# 保留自定义异常类名
-keep public class * extends java.lang.Exception

# 保留Fragment子类及无参构造方法，解决找不到Fragment构造的运行时报错
-keep public class * extends androidx.fragment.app.Fragment
-keep public class * extends android.app.Fragment
-keepclassmembers class * {
    public <init>();
}

# 避免Crashlytics自身逻辑被混淆
-keep class com.google.firebase.crashlytics.** { *; }

同时检查模块级build.gradle的release配置，确保引入了系统默认混淆规则，不要遗漏：

buildTypes {
    release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        firebaseCrashlytics {
            mappingFileUploadEnabled true
        }
    }
}

如果使用AGP 7.0及以上版本，R8默认开启全模式，默认保留规则会进一步裁剪，上述Fragment相关规则必须显式添加，不能依赖默认规则。

• 排查版本与mapping匹配问题
  Crashlytics通过versionCode + versionName关联对应安装包的mapping文件，如果同一个versionCode重复打多个release包，后上传的mapping会覆盖旧文件，导致之前打出的包上报的崩溃无法反混淆。每次正式发版必须升级versionCode，禁止同一versionCode产出多个对外发布的包。
• 注意生效逻辑
  配置修改完成后，历史已经上报到Crashlytics的崩溃不会自动重新反混淆，只有重新打包、安装新构建的包之后，新触发上报的崩溃才会正常显示原始类名、文件名和行号。
  你遇到的Unable to instantiate fragment h.d.p.q.s.b: could not find Fragment constructor本身就是Fragment类被错误混淆导致的运行时异常，补全Fragment相关keep规则后，该崩溃本身也会同步修复。

内容的提问来源于stack exchange，提问作者Vikram Ragu