iOS+
Android
Flutter
Unity
本頁面提供疑難排解說明，並解答有關使用 Crashlytics 的常見問題。如果找不到所需資訊或需要其他協助，請與 Firebase 支援團隊 聯絡。
一般疑難排解/常見問題
找不到導覽標記記錄
如果您沒有看到麵包屑記錄 ，建議您檢查應用程式是否已設定 Google Analytics 。請確認你符合下列規定：
未顯示當機風險驟升警告
如果您沒有看到速度警示，請確認您使用的是
Crashlytics SDK 18.6.0 以上版本 (或 Firebase BoM 32.6.0 以上版本)。
未顯示未發生當機情形的指標 (或顯示不可靠的指標)
如果您沒有看到未發生當機情形的指標 (例如未發生當機情形的使用者和工作階段)，或是看到不準確的指標，請檢查下列項目：
為什麼只有 Android 11 以上版本會回報 ANR？
Crashlytics 支援搭載 Android 11 以上版本的裝置，為 Android 應用程式回報 ANR 問題。我們用來收集 ANR 的基礎 API (getHistoricalProcessExitReasons ) 比 SIGQUIT 或以監視器為基礎的方法更可靠。這個 API 僅適用於 Android 11 以上版本的裝置。
為什麼部分 ANR 缺少 BuildId？
如果部分 ANR 缺少 BuildId，請按照下列步驟排解問題：
請確認您使用的是最新版的 Crashlytics Android SDK 和 Crashlytics Gradle 外掛程式。
如果您缺少 Android 11 和部分 Android 12 ANR 的 BuildId，很可能是因為您使用了過時的 SDK 和/或 Gradle 外掛程式。如要為這些 ANR 正確收集 BuildId，您必須使用下列版本：
Crashlytics Android SDK 18.3.5 以上版本 (Firebase BoM 31.2.2 以上版本)Crashlytics Gradle 外掛程式 2.9.4 以上版本 檢查是否使用非標準位置存放共用程式庫。
如果您只缺少應用程式共用程式庫的 BuildId，很可能是您未使用共用程式庫的標準預設位置。如果是這種情況，Crashlytics 可能無法找到相關聯的 BuildId。建議您考慮使用共用程式庫的標準位置。
請確認您在建構程序中沒有去除 BuildId。
請注意，下列疑難排解提示適用於 ANR 和原生異常終止情形。
請在二進位檔上執行 readelf -n，檢查是否有 BuildId。如果沒有 BuildId，請將 -Wl,--build-id 新增至建構系統的標記。
請確認您並未在縮減 APK 大小時，不小心移除 BuildId。
如果您保留已去除和未去除版本的程式庫，請務必在程式碼中指向正確的版本。
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 控制台中產生不一致的堆疊追蹤記錄。為緩解這個問題，請在建構程序中加入下列連結器標記：
如果您仍看到堆疊追蹤不一致的情形 (或兩個標記都與工具鍊無關)，請改為在建構程序中加入以下項目：
-fno-omit-frame-pointer
如何使用自己的 Breakpad 符號檔案產生器二進位檔，用於 NDK？
Crashlytics 外掛程式會內含自訂的 Breakpad 符號檔案產生器 。如果您偏好使用自己的二進位檔來產生 Breakpad 符號檔案 (例如，如果您偏好從來源建構建構鏈中的所有原生可執行檔)，請使用選用的 symbolGeneratorBinary 擴充功能屬性，指定可執行檔的路徑。
注意： Android 二進位檔需要使用 Linux 版本的 Breakpad 符號檔案產生器。 您可以透過下列兩種方式指定中斷點符號檔案產生器二進位檔的路徑：
選項 1 ：透過 firebaseCrashlytics 擴充功能在 build.gradle 檔案中指定路徑
請將以下內容新增到應用程式層級 build.gradle.kts 檔案中：
Gradle 外掛程式 3.0.0 以上版本
android {
buildTypes {
release {
configure<CrashlyticsExtension> {
nativeSymbolUploadEnabled = true
// Add these optional fields to specify the path to the executable
symbolGeneratorType = "breakpad"
breakpadBinary = file ( "/PATH/TO/BREAKPAD/DUMP_SYMS " )
}
}
}
} 較舊的外掛程式版本
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.breakpadBinary 屬性指定可執行檔的路徑。
您可以手動更新 Gradle 屬性檔案，也可以透過指令列更新檔案。舉例來說，如要透過指令列指定路徑，請使用以下指令：
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
-Pcom.google.firebase.crashlytics.breakpadBinary=/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
為什麼我會看到標示為 .java 問題的 .kt 檔案發生當機？
如果應用程式使用不公開檔案副檔名的模糊處理器，Crashlytics 會根據預設為每個問題產生 .java 副檔名。
為讓 Crashlytics 產生正確的檔案副檔名問題，請確認應用程式使用以下設定：
使用 Android Gradle 4.2.0 以上版本
使用 R8，並啟用模糊處理功能。如要將應用程式更新至 R8，請按照這份說明文件 操作。
請注意，更新至上述設定後，您可能會開始看到與現有 .java 問題重複的新 .kt 問題。請參閱常見問題 ，進一步瞭解這種情況。
為什麼我會看到與現有 .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 Mobile Ads SDK，但不會發生當機問題
如果您的專案同時使用 Crashlytics 和 Google Mobile Ads SDK，當機回報程式在註冊例外狀況處理常式時，很可能會造成干擾。如要修正這個問題，請呼叫 disableSDKCrashReporting，關閉 Mobile Ads SDK 中的當機回報功能。
我的 BigQuery 資料集位於何處？
將 Crashlytics 連結至 BigQuery 後，無論 Firebase 專案位於何處，您建立的新資料集都會自動位於美國。
Crashlytics 是否支援 armeabi？
Firebase Crashlytics NDK 不支援 ARMv5 (armeabi)。自 NDK r17 起，我們已停止支援這個 ABI。
迴歸的問題
什麼是回歸問題？
當您先前已關閉問題，但 Crashlytics 收到問題再度發生的新報表時，就表示該問題已迴歸。Crashlytics 會自動重新開啟這些回歸問題，方便您根據應用程式需求妥善處理。
以下是說明 Crashlytics 如何將問題歸類為迴歸的範例情境：
Crashlytics 首次收到「A」當機事件的當機報告。Crashlytics 會開啟與該當機狀況相對應的問題 (問題「A」)。您迅速修正這個錯誤、關閉「A」問題，然後發布新版應用程式。
Crashlytics 在您關閉問題「A」後，收到另一份相關報告。
如果報告來自 Crashlytics 已知 的應用程式版本 (也就是該版本已傳送「任何」Crashlytics 就不會將該問題視為回退。問題仍會維持關閉狀態。
如果回報內容來自 Crashlytics 在您關閉問題時「未知」Crashlytics 會將問題視為迴歸，並重新開啟問題。
注意： 在 2022 年 2 月之前，Crashlytics 會將問題歸類為回歸問題，只要該問題在任何 應用程式版本中再次發生，即使是您關閉問題時已知的應用程式版本，也是如此。這導致 Crashlytics 有時會不正確識別回歸。我們現在使用上述慣例。 當問題發生迴歸時，我們會傳送迴歸偵測警示，並在問題中新增迴歸信號，讓您知道 Crashlytics 已重新開啟問題。如果不希望問題因回歸演算法而重新開啟，請「靜默」問題，而非關閉問題。
為什麼我會看到舊版應用程式出現的回退問題？
如果回報來自舊版應用程式，且在您關閉問題時從未傳送任何當機報告，Crashlytics 就會將該問題視為迴歸，並重新開啟問題。
這種情況可能發生在以下情況：您修正了錯誤並發布新版應用程式，但仍有使用者使用未修正錯誤的舊版。如果您在關閉問題時，其中一個舊版本從未 傳送任何當機報告，而這些使用者開始遇到錯誤，則這些當機報告會觸發回歸問題。
如果不希望問題因回歸演算法而重新開啟，請「暫停」問題，而非關閉問題。
注意： 在 2022 年 2 月之前，Crashlytics 會將任何應用程式版本中再次發生的問題歸類為迴歸問題，即使您關閉問題時已知曉該問題的應用程式版本也是如此。這導致 Crashlytics 有時會不正確識別回歸。我們現在使用上述慣例。
