本页面提供了问题排查帮助，并解答了有关使用 Crashlytics 的常见问题。如果您找不到想要的内容或需要其他帮助，请与 Firebase 支持团队联系。
常规问题排查/常见问题解答
没有看到“未遇到崩溃问题的用户数”“面包屑导航日志”和/或“疾速崩溃提醒”
如果您没有看到“未遇到崩溃问题的用户数”“面包屑导航日志”和/或“疾速崩溃提醒”，我们建议您检查应用的 Google Analytics（分析）配置。
确保您已在 Firebase 项目中启用 Google Analytics（分析）。
确保已在 Firebase 控制台的“集成”> Google Analytics（分析）页面中为 Google Analytics（分析）启用了“数据共享”。请注意，“数据共享”设置显示在 Firebase 控制台中，但在 Google Analytics（分析）控制台中进行管理。
除了 Firebase Crashlytics SDK，请确保您已将 Firebase SDK for Google Analytics 添加到您的应用 (iOS+ | Android) 中。
对于所有 Firebase SDK (iOS+ | Android)，请确保您使用的是最新版本。
特别要确认您使用的 Firebase SDK for Google Analytics 是否至少为以下版本：iOS+ - v6.3.1+ （macOS 和 tvOS 为 v8.9.0+）|Android - v17.2.3+ (BoM v24.7.1+) 。
在“问题”表格中看到两种不同的格式
您可能会注意到，Firebase 控制台的“问题”表格中列出的问题有两种不同的格式。原因如下：
Crashlytics 会分析应用的所有事件（崩溃事件、非严重事件和 ANR 事件），并将类似事件划分到单独的问题中。2023 年 1 月，我们发布了经过改进的分析引擎，用于根据应用的代码对事件进行分组，并更新了用于显示新问题的设计。
改进后的体验如下：
改进了问题行中显示的元数据
现在，您可以更轻松地了解应用中的问题并进行分类。减少重复问题
更改行号不会导致新问题。更有意义的提醒和信号
新问题表示真的出现了新的 bug。更强大的搜索功能
每个问题都包含更易于搜索的元数据，例如异常类型和软件包名称。
具体改进措施如下：
从您的应用获取新事件时，我们会检查这些事件是否与现有问题匹配。
如果没有匹配项，我们会自动为事件应用更智能的事件分组算法，并使用改进后的元数据设计创建新的问题。
这是我们对事件分组进行的第一次重大更新。如果您有任何反馈或遇到任何问题，请通过提交报告告诉我们。
为什么仅对 Android 11 及更高版本报告 ANR？
Crashlytics 支持对搭载 Android 11 及更高版本的设备中的 Android 应用报告 ANR。我们用于收集 ANR 的底层 API (getHistoricalProcessExitReasons) 比基于 SIGQUIT 或基于监控定时器的方法更加可靠。此 API 仅适用于 Android 11 及更高版本的设备。
Crashlytics 信息中心和 Google Play 管理中心的 ANR 报告之间的区别
Google Play 和 Crashlytics 中的 ANR 计数可能不一致。这在意料之中，因为两者的 ANR 数据收集和报告机制有所不同。Crashlytics 会在应用下次启动时报告 ANR，而 Android Vitals 会在发生 ANR 后即刻发送 ANR 数据。
此外，Crashlytics 仅显示搭载 Android 11 及更高版本的设备上发生的 ANR，而 Google Play 则显示使用 Google Play 服务且同意进行数据收集的设备上的 ANR。
Crashlytics 信息中心和 Logcat 中的 NDK 堆栈轨迹之间的差异
LLVM 和 GNU 工具链针对您应用中的二进制文件只读段提供不同的默认值和处理方式，这可能会在 Firebase 控制台中生成不一致的堆栈轨迹。如需缓解此问题，请在构建流程中添加以下链接器标志：
如果您使用的是 LLVM 工具链中的
lld链接器，请添加：-Wl,--no-rosegment如果您使用的是 GNU 工具链中的
ld.gold链接器，请添加：-Wl,--rosegment
如果堆栈轨迹仍不一致（或者两个标志都不适用于您的工具链），请试试将以下内容添加到构建流程：
-fno-omit-frame-pointer
如何将我自己的 Breakpad 符号文件生成器二进制程序用于 NDK？
Crashlytics 插件捆绑了一个定制的 Breakpad 符号文件生成器。
如果您希望使用自己的二进制程序来生成 Breakpad 符号文件（例如，如果您希望在自己的 build 链中从源代码构建所有原生可执行文件），请使用可选的 symbolGeneratorBinary 扩展属性来指定可执行文件的路径。
您可以通过以下方法指定 Breakpad 符号文件生成器二进制程序的路径：
方法 1：在
build.gradle文件中通过firebaseCrashlytics扩展指定路径将以下内容添加到您的应用级
build.gradle文件：android { // ... buildTypes { // ... release { // ... firebaseCrashlytics { // existing; required for either symbol file generator nativeSymbolUploadEnabled true // Add this optional new block to specify the path to the executable symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }方法 2：在 Gradle 属性文件中通过属性行指定路径
您可以使用
com.google.firebase.crashlytics.symbolGeneratorBinary属性指定可执行文件的路径。您可以手动更新 Gradle 属性文件，也可以通过命令行更新此文件。例如，如需通过命令行指定路径，请使用如下命令：
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
使用 DexGuard 时无法收到崩溃信息
如果您看到以下异常，可能是因为您使用的 DexGuard 版本与 Firebase Crashlytics SDK 不兼容：
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
此异常不会导致您的应用崩溃，但会阻止其发送崩溃报告。如需修复此问题，请执行以下操作：
确保您使用的是最新版 DexGuard 8.x。最新版本包含 Firebase Crashlytics SDK 所需的规则。
如果您不希望更改 DexGuard 版本，请尝试（在 DexGuard 配置文件中）向混淆规则添加以下内容：
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
为什么因 .kt 文件造成的崩溃被标为 .java 问题？
如果应用使用的是不显示文件扩展名的 obfuscator（混淆器），Crashlytics 会默认以 .java 文件扩展名生成问题。
为了让 Crashlytics 生成的问题带有正确的文件扩展名，请确保您的应用使用以下设置：
- 使用 Android Gradle 4.2.0 或更高版本
- 使用 R8 且启用混淆功能。如需将应用更新到 R8，请按照此文档进行操作。
请注意，在更新到上述设置后，您可能会看到新的 .kt 问题，它们与现有的 .java 问题重复。请参阅常见问题解答，详细了解这种情况。
为什么 .kt 问题与现有的 .java 问题重复？
从 2021 年 12 月中旬开始，Crashlytics 改进了对使用 Kotlin 的应用的支持。
不久之前，可用的混淆器都不显示文件扩展名，因此 Crashlytics 默认以 .java 文件扩展名生成各个问题。不过，从 Android Gradle 4.2.0 开始，R8 支持文件扩展名。
经过此次更新，Crashlytics 现在可以确定应用中使用的每个类是否是以 Kotlin 编写的，并在问题签名中包含正确的文件名。如果您的应用采用以下设置，则崩溃现在可以正确归因于 .kt 文件（如果适用）：
- 您的应用使用 Android Gradle 4.2.0 或更高版本。
- 您的应用使用 R8 且已启用混淆功能。
由于新崩溃的问题签名中现在包含正确的文件扩展名，因此您可能会看到新的 .kt 问题，而这些问题实际上与标记为 .java 的现有问题重复。在 Firebase 控制台中，我们会尝试识别新的 .kt 问题是否与标记为 .java 的现有问题重复，并通知您。
如何计算未遇到崩溃问题的用户？
“未遇到崩溃问题的用户”值表示与您的应用互动过，但在特定时间段内未遇到崩溃问题的用户所占的百分比。
以下是计算未遇到崩溃问题的用户所占百分比的公式。其输入值由 Google Analytics（分析）提供。
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100
发生崩溃时，Google Analytics（分析）会发送
app_exception事件类型，CRASHED_USERS 表示与该事件类型关联的用户数量。ALL_USERS 表示在您从 Crashlytics 信息中心右上角的下拉菜单中选择的时间段内与您的应用互动的用户总数。
未遇到崩溃问题的用户所占的百分比是一段时间内的汇总情况，而非平均值。
例如，假设您的应用有 3 位用户；我们将其称为用户 A、用户 B 和用户 C。下表显示了哪些用户每天与您的应用互动，以及其中哪些用户在当天发生了崩溃：
| 星期一 | 星期二 | 星期三 | |
|---|---|---|---|
| 与您的应用互动过的用户 | A、B、C | A、B、C | A、B |
| 发生崩溃的用户 | C | B | A |
在星期三，未遇到崩溃问题的用户所占百分比为 50%（1/2 的用户未遇到崩溃问题）。
有 2 位用户在周三与您的应用互动过，但其中只有 1 位用户（用户 B）没有遇到崩溃问题。在过去 2 天内，未遇到崩溃问题的用户所占百分比为 33.3%（1/3 的用户未遇到崩溃问题）。
3 位用户在过去 2 天内与您的应用互动过，但其中只有 1 位用户 (C) 未遇到崩溃问题。在过去 3 天内，未遇到崩溃问题的用户所占百分比为 0%（所有 3 个用户都遇到了崩溃问题）。
3 位用户在过去 3 天内与您的应用进行了互动，但这 3 位用户都遇到了崩溃问题。
谁可以查看、撰写和删除问题的备注？
借助备注功能，项目成员可以就相关疑问或状态更新等特定问题进行备注。
项目成员发布备注时，系统会标注其 Google 帐号的电子邮件地址。此电子邮件地址将与备注一起向有权访问备注的所有项目成员显示。
下文介绍了查看、撰写和删除备注所需的权限：
具有以下任一角色的项目成员均可查看和删除现有备注，还可以就某个问题撰写新备注。
具有以下任一角色的项目成员均可查看针对某个问题发布的备注，但无法删除或撰写备注。
集成
应用还使用了 Google 移动广告 SDK，但无法收到崩溃信息
如果您的项目同时使用 Crashlytics 和 Google 移动广告 SDK，这可能是由于在注册异常处理程序时，崩溃报告工具进行了干扰。如需解决此问题，请调用 disableSDKCrashReporting，在移动广告 SDK 中关闭崩溃报告。
我的 BigQuery 数据集位于何处？
无论您的 Firebase 项目位于何处，将 Crashlytics 关联到 BigQuery 后，您创建的新数据集都会自动采用美国位置。
平台支持
Crashlytics 是否支持 armeabi？
Firebase Crashlytics NDK 不支持 ARMv5 (armeabi)。从 NDK r17 开始，我们不再支持此 ABI。
回归问题
什么是回归问题？
如果您之前修复并关闭了某个问题，但 Crashlytics 收到了一个该问题再次发生的新报告，则表明该问题已回归。Crashlytics 会自动重新打开这些回归问题，以便您可以根据自己的应用需求采取相应措施。
以下示例场景说明了 Crashlytics 如何将问题归类为回归问题：
- Crashlytics 首次收到有关崩溃“A”的崩溃报告。Crashlytics 会为该崩溃打开相应的问题（问题“A”）。
- 您快速修复此 bug，关闭问题“A”，然后发布应用的新版本。
- 在您关闭问题后，Crashlytics 收到关于问题“A”的另一份报告。
- 如果报告来自 Crashlytics 在您关闭问题时知道的应用版本（这意味着该版本已针对任何崩溃发送了崩溃报告），则 Crashlytics 不会将问题视为回归。此问题将保持关闭状态。
- 如果报告来自 Crashlytics 在您关闭问题时不知道的应用版本（这意味着该版本从未针对任何崩溃发送过崩溃报告），则 Crashlytics 会将该问题视为回归问题，并将其重新打开。
当某个问题回归时，我们会发送回归检测提醒，并向该问题添加回归信号，让您知道 Crashlytics 已经重新打开了问题。如果您不希望由于回归算法而要重新打开问题，请“忽略”问题，而不是将其关闭。
为什么我看到旧版应用的回归问题？
如果报告来自在您关闭问题时从未发送过任何崩溃报告的旧应用版本，则 Crashlytics 会认为问题已回归，并会重新打开问题。
在以下情况下，可能会出现这种情形：您已修复了一个 bug，并发布了应用的新版本，但仍有一些用户使用的是旧版本，而且未进行 bug 修复。如果偶然情况下，当您关闭问题时，其中一个旧版本根本没有发送过任何崩溃报告，并且这些用户开始遇到 bug，那么这些崩溃报告将触发回归问题。
如果您不希望由于回归算法而要重新打开问题，请“忽略”问题，而不是将其关闭。