Android端Firebase Crashlytics测试崩溃无日志上报如何排查

问题现状 #

完成Firebase Crashlytics全流程接入后，主动触发测试崩溃，开启调试日志可观察到：崩溃异常已完成本地持久化、成功入队到DataTransport上报层，但日志中完全缺失后续网络上报的状态记录，等待超48小时后Firebase控制台仍无对应崩溃记录。

捕获到的调试日志片段：

D/FirebaseCrashlytics(23841): Crashlytics is handling uncaught exception "java.lang.RuntimeException: Unable to start activity ComponentInfo{com. ... .TabActivity}: java.lang.NumberFormatException: Invalid int: "abc"" from thread main
D/FirebaseCrashlytics(23841): Persisting fatal event for session 603B968F001F00015D21614184AB1DFB
D/FirebaseCrashlytics: Finalizing report for session 603B968F001F00015D21614184AB1DFB
D/FirebaseCrashlytics: Opening a new session with ID 603B9693009B00025D21614184AB1DFB
D/FirebaseCrashlytics: Crashlytics automatic data collection ENABLED by global Firebase setting.
D/FirebaseCrashlytics: Logging Crashlytics event to Firebase
D/FirebaseCrashlytics: Awaiting app exception callback from FA...
D/FirebaseCrashlytics: Received Analytics message: 3 Bundle[{params=Bundle[{_o=clx, _r=1, timestamp=1614517907044, fatal=1}], name=_ae, timestampInMillis=1614517907169}]
D/FirebaseCrashlytics: App exception callback received from FA listener.
D/FirebaseCrashlytics: Crashlytics report successfully enqueued to DataTransport: 603B968F001F00015D21614184AB1DFB
D/FirebaseCrashlytics: Crashlytics completed exception processing. Invoking default exception handler.

正常网络通畅场景下，入队操作完成后会补充输出如下日志：

TransportRuntime.CctTransportBackend: Making request to with subsequent 
TransportRuntime.CctTransportBackend: Status Code: 200

核心排查步骤 #

• 排查网络上报链路阻断问题
  入队操作仅代表崩溃数据写入本地待上报队列，不代表数据完成了网络传输。优先从链路层验证：
  • 确认应用Manifest中已声明INTERNET、ACCESS_NETWORK_STATE基础网络权限
  • 交叉核对数据收集开关配置，哪怕日志提示自动收集已启用，也要排查Manifest中是否存在手动关闭采集的配置：

    <!-- 会阻断上报的错误配置示例 -->
    <meta-data android:name="firebase_crashlytics_collection_enabled" android:value="false" />
    <meta-data android:name="firebase_data_collection_default_enabled" android:value="false" />
    

  • 排查设备是否启用VPN、网络代理，或当前办公网络拦截了Crashlytics上报域名，可切换设备到公共移动网络环境重新测试，观察日志中是否出现Transport层的请求记录
• 核对依赖版本与构建配置匹配性
  版本错配、构建流程配置错误是导致本地入队成功但服务端丢弃数据的高频原因：
  • 保证Google服务插件、Crashlytics插件、Firebase BOM依赖版本严格遵循官方兼容要求，不要跨大版本混用SDK与插件
  • 确认模块级构建脚本中插件的应用顺序：Crashlytics插件必须在Google服务插件之后应用，否则会出现符号映射不匹配，导致上报数据被服务端直接过滤
• 手动触发强制上报流程
  Crashlytics默认会在应用下次启动时批量上传队列中的崩溃数据，可缩短验证周期：
  • 触发崩溃后，不要直接强杀应用，将应用退到后台静置60秒以上，观察日志中是否触发自动上报
  • 可通过代码主动调用Crashlytics.getInstance().sendUnsentReports()，强制立即上传本地所有未上报的崩溃记录，网络通畅时日志中会立刻出现Transport层的状态码输出
• 核对服务端项目匹配性
  • 检查应用的包名、签名SHA值是否和Firebase控制台中登记的应用信息完全一致，信息不匹配会导致上报数据被服务端直接丢弃
  • 确认登录账号拥有对应项目的Crashlytics模块查看权限，不要在错误项目、错误应用入口下检索崩溃记录
  • 调整控制台的时间筛选范围，测试触发的崩溃数据不会直接显示在首页概览，需要进入Crashlytics专属模块的崩溃列表页，排除默认筛选规则的影响

常见认知误区：网传“崩溃数据需要24-48小时同步”是早期版本的旧规则，当前版本Crashlytics只要上报成功，一般5分钟内即可在控制台检索到记录，超过这个周期无记录基本都是本地上报链路存在阻断，不是服务端同步延迟。

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