此頁面提供故障排除幫助和有關使用 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 控制台的問題表中列出的問題有兩種不同的格式。您可能還會注意到在您的某些問題中稱為“變體”的功能。這就是為什麼！
2023 年初，我們推出了改進的事件分組分析引擎以及更新的設計和一些針對新問題（如變體！）的高級功能。查看我們最近的博客文章了解所有詳細信息，但您可以閱讀下面的重點內容。
Crashlytics 分析您應用中的所有事件（例如崩潰、非致命事件和 ANR）並創建稱為問題的事件組——一個問題中的所有事件都有一個共同的故障點。
為了將事件分組到這些問題中，改進的分析引擎現在會查看事件的許多方面，包括堆棧跟踪中的幀、異常消息、錯誤代碼和其他平台或錯誤類型特徵。
但是，在這組事件中，導致失敗的堆棧跟踪可能不同。不同的堆棧跟踪可能意味著不同的根本原因。為了表示問題中的這種可能差異，我們現在在問題中創建變體——每個變體都是問題中具有相同故障點和相似堆棧跟踪的事件的子組。使用變體，您可以調試問題中最常見的堆棧跟踪，並確定是否有不同的根本原因導致失敗。
以下是您將體驗到的這些改進：
問題行中顯示的改進元數據
現在可以更輕鬆地理解和分類應用中的問題。更少的重複問題
行號更改不會導致新問題。更容易調試具有各種根本原因的複雜問題
使用變體調試問題中最常見的堆棧跟踪。更有意義的警報和信號
一個新問題實際上代表一個新錯誤。更強大的搜索
每個問題都包含更多可搜索的元數據，例如異常類型和包名稱。
以下是這些改進的實施方式：
當我們從您的應用中獲得新事件時，我們將檢查它們是否與現有問題相匹配。
如果沒有匹配項，我們將自動將更智能的事件分組算法應用於事件，並使用改進後的元數據設計創建新問題。
這是我們對事件分組進行的第一次重大更新。如果您有任何反饋或遇到任何問題，請通過提交報告讓我們知道。
Crashlytics 支持來自運行 Android 11 及更高版本的設備的 Android 應用的 ANR 報告。我們用來收集 ANR 的底層 API ( getHistoricalProcessExitReasons ) 比 SIGQUIT 或基於看門狗的方法更可靠。此 API 僅適用於 Android 11+ 設備。
如果您的某些 ANR 缺少它們的BuildId ，請按以下方式進行故障排除：
確保您使用的是最新的 Crashlytics Android SDK 和 Crashlytics Gradle 插件版本。
如果您缺少適用於 Android 11 的
BuildId和一些 Android 12 ANR，那麼您可能使用的是過時的 SDK、Gradle 插件或兩者。要正確收集這些 ANR 的BuildId，您需要使用以下版本：- Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
- Crashlytics Gradle 插件 v2.9.4+
檢查您是否為共享庫使用了非標準位置。
如果您只是缺少應用程序共享庫的
BuildId，則很可能您沒有使用共享庫的標準默認位置。如果是這種情況，則 Crashlytics 可能無法找到關聯的BuildId。我們建議您考慮使用共享庫的標準位置。確保您在構建過程中沒有剝離
BuildId。請注意，以下故障排除提示適用於 ANR 和本機崩潰。
通過在您的二進製文件上運行
readelf -n來檢查BuildId是否存在。如果BuildId不存在，則將-Wl,--build-id添加到構建系統的標誌中。檢查您是否無意中剝離了
BuildId以減小 APK 大小。如果您保留庫的剝離和未剝離版本，請確保在代碼中指向正確的版本。
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 | 乙 | A |
星期三，您的無崩潰用戶百分比為 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 會認為該問題已回歸併將重新打開該問題。
這種情況可能發生在以下情況：您已經修復了一個錯誤並發布了應用的新版本，但您仍然有用戶使用未修復錯誤的舊版本。如果碰巧，當您關閉問題時，其中一個舊版本根本沒有發送任何崩潰報告，並且這些用戶開始遇到該錯誤，那麼這些崩潰報告將觸發回歸問題。
如果您不希望某個問題因我們的回歸算法而重新打開，請“靜音”該問題而不是將其關閉。