此頁面提供故障排除協助以及有關使用 Crashlytics 的常見問題。如果您找不到所需內容或需要其他協助,請聯絡Firebase 支援。
一般故障排除/常見問題解答
您可能會注意到 Firebase 控制台的問題表中列出的問題有兩種不同的格式。您可能還會注意到某些問題中有一個稱為“變體”的功能。這就是原因!
2023 年初,我們推出了改進的用於對事件進行分組的分析引擎,以及針對新問題(如變體!)的更新設計和一些高級功能。請查看我們最近的部落格文章以了解所有詳細信息,但您可以閱讀下面的重點內容。
Crashlytics 分析應用程式中的所有事件(例如崩潰、非致命事件和 ANR)並建立稱為問題的事件群組 - 問題中的所有事件都有一個共同的故障點。
為了將事件分組到這些問題中,改進的分析引擎現在會查看事件的許多方面,包括堆疊追蹤中的幀、異常訊息、錯誤代碼以及其他平台或錯誤類型特徵。
但是,在這組事件中,導致失敗的堆疊追蹤可能有所不同。不同的堆疊追蹤可能意味著不同的根本原因。為了表示問題中可能存在的差異,我們現在在問題中創建變體- 每個變體是問題中具有相同故障點和類似堆疊追蹤的事件的子組。透過變體,您可以調試問題中最常見的堆疊跟踪,並確定是否有不同的根本原因導致失敗。
以下是您將體驗到的這些改進:
修改了問題行中顯示的元數據
現在可以更輕鬆地理解和分類應用程式中的問題。減少重複問題
行號更改不會導致新問題。更輕鬆地調試具有各種根本原因的複雜問題
使用變體來調試問題中最常見的堆疊追蹤。更有意義的警報和信號
一個新的問題實際上代表一個新的bug。更強大的搜尋
每個問題都包含更多可搜尋的元數據,例如異常類型和套件名稱。
以下是這些改進的實施方式:
當我們從您的應用程式收到新事件時,我們將檢查它們是否與現有問題相符。
如果沒有匹配,我們將自動將更聰明的事件分組演算法應用於該事件,並使用改進的元資料設計建立新問題。
這是我們對活動分組進行的第一次重大更新。如果您有回饋或遇到任何問題,請透過提交報告告知我們。
如果您沒有看到無崩潰指標(例如無崩潰使用者和會話)和/或速度警報,請確保您使用的是Crashlytics SDK v18.6.0+(或 Firebase BoM v32.6.0+)。
如果您沒有看到麵包屑日誌,我們建議您檢查應用程式的 Google Analytics(分析)配置。確保您符合以下要求:
您已在 Firebase 專案中啟用 Google Analytics 。
您已啟用 Google Analytics(分析)資料共享。在管理您的 Analytics 資料共享設定中了解有關此設定的更多信息
您已新增了適用於 Google Analytics 的Firebase SDK加入到您的應用程式中。除了Crashlytics SDK 之外,還必須加入此 SDK。
對於您在應用程式中使用的所有產品,您正在使用最新 Firebase SDK 版本。
特別檢查您是否至少使用以下版本的 Firebase SDK for Google Analytics:
Android — v17.2.3+ (BoM v24.7.1+) 。
Crashlytics 支援運行 Android 11 及更高版本的裝置上的 Android 應用程式的 ANR 報告。我們用來收集 ANR ( getHistoricalProcessExitReasons ) 的底層 API 比 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
加入到建置系統的標誌中。檢查您是否沒有為了減小 APK 大小而無意中刪除
BuildId
。如果您保留庫的剝離和未剝離版本,請確保在程式碼中指向正確的版本。
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 帳戶的電子郵件地址。所有有權查看註釋的項目成員都可以看到此電子郵件地址以及註釋。
以下描述了查看、寫入和刪除筆記所需的存取權限:
具有以下任何角色的專案成員可以查看和刪除現有註釋以及針對問題編寫新註釋。
具有以下任何角色的專案成員可以查看針對問題發布的註釋,但無法刪除或寫入註釋。
請參閱了解無崩潰指標。
註釋允許專案成員對特定問題發表評論,包括問題、狀態更新等。
當專案成員發布註釋時,該註釋會標示其 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 會認為問題已退化,並將重新開啟問題。
在以下情況下可能會發生這種情況:您已修復了錯誤並發布了應用程式的新版本,但仍有用戶使用未修復錯誤的舊版本。如果碰巧,當您關閉問題時,這些舊版本之一從未發送任何崩潰報告,並且這些用戶開始遇到該錯誤,那麼這些崩潰報告將觸發回歸問題。
如果您不希望由於我們的回歸演算法而重新開啟某個問題,請「靜音」該問題而不是關閉它。