此页面提供故障排除帮助和有关使用 Crashlytics 的常见问题解答。如果找不到您要查找的内容或需要其他帮助，请联系Firebase 支持。
一般故障排除/常见问题解答
如果您没有看到无崩溃的用户、面包屑日志和/或速度警报，我们建议您检查您的应用的 Google Analytics 配置。
确保您已在 Firebase 项目中启用了 Google Analytics 。
确保在 Firebase 控制台的集成> Google Analytics页面中为 Google Analytics 启用数据共享。请注意，数据共享设置显示在 Firebase 控制台中，但在 Google Analytics 控制台中进行管理。
除了 Firebase Crashlytics SDK 之外，请确保您已将适用于 Google Analytics 的 Firebase SDK 添加到您的应用程序 ( iOS+ | Android )。
确保您使用的是所有 Firebase SDK ( iOS+ | Android ) 的最新版本。
特别要检查您是否至少使用以下版本的 Google Analytics Firebase SDK： iOS+ — v6.3.1+（v8.9.0+ for macOS 和 tvOS）| Android — v17.2.3+(BoM v24.7.1+) 。
您可能会注意到 Firebase 控制台的问题表中列出的问题有两种不同的格式。这就是为什么！
Crashlytics 分析您应用中的所有事件——崩溃、非致命事件和 ANR——并将类似的事件分组到不同的问题中。 2023 年 1 月，我们推出了改进的分析引擎，用于根据您的应用代码对事件进行分组，并推出了用于显示新问题的更新设计。
以下是您将体验到的这些改进：
问题行中显示的改进元数据
现在可以更轻松地理解和分类应用中的问题。更少的重复问题
行号更改不会导致新问题。更有意义的警报和信号
一个新问题实际上代表一个新错误。更强大的搜索
每个问题都包含更多可搜索的元数据，例如异常类型和包名称。
以下是这些改进的实施方式：
当我们从您的应用中获得新事件时，我们将检查它们是否与现有问题相匹配。
如果没有匹配项，我们将自动将更智能的事件分组算法应用于事件，并使用改进后的元数据设计创建新问题。
Crashlytics 支持来自运行 Android 11 及更高版本的设备的 Android 应用的 ANR 报告。我们用来收集 ANR 的底层 API ( getHistoricalProcessExitReasons ) 比 SIGQUIT 或基于看门狗的方法更可靠。此 API 仅适用于 Android 11+ 设备。
Google Play 和 Crashlytics 之间的 ANR 计数可能不匹配。这是预期的，因为收集和报告 ANR 数据的机制不同。 Crashlytics 在应用下次启动时报告 ANR，而 Android Vitals 在 ANR 发生后发送 ANR 数据。
此外，Crashlytics 仅显示运行 Android 11+ 的设备上发生的 ANR，而 Google Play 显示来自具有 Google Play 服务并接受数据收集同意的设备的 ANR。
LLVM 和 GNU 工具链对应用程序二进制文件的只读部分有不同的默认设置和处理方式，这可能会在 Firebase 控制台中生成不一致的堆栈跟踪。为了缓解这种情况，请将以下链接器标志添加到您的构建过程中：
如果您使用的是 LLVM 工具链中的
lld链接器，请添加：-Wl,--no-rosegment如果您使用 GNU 工具链中的
ld.gold链接器，请添加：-Wl,--rosegment
如果您仍然看到堆栈跟踪不一致（或者如果这两个标志都与您的工具链无关），请尝试将以下内容添加到您的构建过程中：
-fno-omit-frame-pointer
Crashlytics 插件捆绑了一个定制的 Breakpad 符号文件生成器。如果您更喜欢使用自己的二进制文件来生成 Breakpad 符号文件（例如，如果您更喜欢从源代码构建构建链中的所有本机可执行文件），请使用可选的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 版本与 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
当应用程序使用不公开文件扩展名的混淆器时，Crashlytics 默认生成每个带有.java文件扩展名的问题。
为了使 Crashlytics 可以生成正确文件扩展名的问题，请确保您的应用使用以下设置：
- 使用 Android Gradle 4.2.0 或更高版本
- 使用开启混淆的 R8。要将您的应用程序更新到 R8，请遵循此文档。
请注意，更新到上述设置后，您可能会开始看到与现有.java问题重复的新.kt问题。请参阅常见问题解答以了解有关该情况的更多信息。
从 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 仪表板右上角的下拉菜单中选择的时间段内与您的应用互动的用户总数。
无崩溃用户百分比是一段时间内的聚合，而不是平均值。
例如，假设您的应用程序有三个用户；我们称他们为用户 A、用户 B 和用户 C。下表显示了每天有哪些用户与您的应用互动，以及哪些用户当天发生了崩溃：
| 周一 | 周二 | 周三 | |
|---|---|---|---|
| 与您的应用互动的用户 | 甲、乙、丙 | 甲、乙、丙 | 一个，乙 |
| 发生崩溃的用户 | C | 乙 | 一种 |
星期三，您的无崩溃用户百分比为 50%（2 个用户中有 1 个没有崩溃）。
您的两名用户在周三使用了您的应用，但只有其中一名（用户 B）没有崩溃。在过去 2 天内，您的无崩溃用户百分比为 33.3%（每 3 个用户中就有 1 个没有崩溃）。
在过去的两天里，您的三位用户与您的应用进行了互动，但其中只有一位（用户 C）没有发生崩溃。在过去 3 天内，您的无崩溃用户百分比为 0%（3 个用户中有 0 个没有崩溃）。
在过去三天里，您的三位用户与您的应用进行了互动，但其中零位用户没有发生崩溃。
注释允许项目成员通过问题、状态更新等对特定问题进行评论。
当项目成员发布注释时，它会标有他们的 Google 帐户的电子邮件地址。所有有权查看注释的项目成员都可以看到此电子邮件地址以及注释。
下面描述了查看、写入和删除笔记所需的访问权限：
具有以下任何角色的项目成员都可以查看和删除现有注释并在问题上编写新注释。
具有以下任何角色的项目成员可以查看发布在问题上的注释，但他们不能删除或编写注释。
集成
如果您的项目将 Crashlytics 与 Google 移动广告 SDK 一起使用，则崩溃报告器可能会在注册异常处理程序时进行干扰。要解决此问题，请通过调用disableSDKCrashReporting关闭移动广告 SDK 中的崩溃报告。
将 Crashlytics 关联到 BigQuery 后，无论您的 Firebase 项目位于何处，您创建的新数据集都会自动位于美国。
平台支持
Firebase Crashlytics NDK 不支持 ARMv5 (armeabi)。自 NDK r17 起，已移除对此 ABI 的支持。
回归问题
当您之前关闭问题时，问题已经回归，但 Crashlytics 收到一份新报告，表明问题再次发生。 Crashlytics 会自动重新打开这些倒退的问题，以便您可以根据您的应用适当地解决它们。
下面是一个示例场景，解释了 Crashlytics 如何将问题归类为回归：
- Crashlytics 有史以来第一次收到有关崩溃“A”的崩溃报告。 Crashlytics 为该崩溃打开一个相应的问题（问题“A”）。
- 您快速修复此错误，关闭问题“A”，然后发布新版本的应用程序。
- 在您关闭问题后，Crashlytics 会收到有关问题“A”的另一份报告。
- 如果报告来自 Crashlytics 在您关闭问题时知道的应用程序版本（意味着该版本已针对任何崩溃发送了崩溃报告），则 Crashlytics 不会将该问题视为倒退。该问题将保持关闭状态。
- 如果报告来自您关闭问题时 Crashlytics不知道的应用程序版本（意味着该版本根本没有针对任何崩溃发送任何崩溃报告），那么 Crashlytics 会认为问题已倒退并会重新打开问题.
当问题回归时，我们会发送回归检测警报并向问题添加回归信号，让您知道 Crashlytics 已重新打开问题。如果您不希望某个问题因我们的回归算法而重新打开，请“静音”该问题而不是将其关闭。
如果报告来自在您关闭问题时根本未发送过任何崩溃报告的旧应用程序版本，则 Crashlytics 会认为该问题已回归并将重新打开该问题。
这种情况可能发生在以下情况：您已经修复了一个错误并发布了应用的新版本，但您仍然有用户使用未修复错误的旧版本。如果碰巧，当您关闭问题时，其中一个旧版本根本没有发送任何崩溃报告，并且这些用户开始遇到该错误，那么这些崩溃报告将触发回归问题。
如果您不希望某个问题因我们的回归算法而重新打开，请“静音”该问题而不是将其关闭。