iOS+
Android
Flutter
Unity
本頁提供疑難排解說明，以及常見問題的解答
有關使用 Crashlytics 的問題。如果找不到所需資訊或需要其他協助，請與 Firebase 支援團隊 聯絡。
一般疑難排解/常見問題
未顯示
未發生當機情形的指標和/或當機風險驟升快訊
如果您沒有看到無當機指標 (例如無當機的使用者和工作階段) 和/或速度快訊，請確認您使用的是
Crashlytics SDK 18.6.0 以上版本 (或 Firebase BoM 32.6.0 以上版本)。
找不到導覽標記記錄
如果您沒有看到麵包屑記錄 ，建議您檢查應用程式是否已設定 Google Analytics 。請確認你符合下列規定：
為何只有 Android 11 以上版本會回報 ANR？
Crashlytics 支援從執行的裝置中，為 Android 應用程式回報 ANR 情形
Android 11 以上版本。我們用來收集 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 新增至
建構系統
確認您沒有刻意移除 BuildId
縮減 APK 大小
如果您保留已去除和未去除版本的程式庫，請務必在程式碼中指向正確的版本。
Crashlytics 資訊主頁和 Google Play 管理中心的 ANR 報告差異
Google Play 和 Google Play 之間的 ANR 次數可能不一致
Crashlytics 。這是預期中的情況，因為收集和回報 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 擴充功能屬性，指定可執行檔的路徑。
注意： 您必須具備 Linux 版的 Breakpad 符號檔案產生器
Android 二進位檔。 您可以指定 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 問題。請參閱常見問題 ，進一步瞭解這種情況。
為什麼我會看到
有 .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 的電子郵件
讓他們使用服務帳戶所有可查看備註的專案成員都能看到這個電子郵件地址和備註。
以下說明查看、寫入及刪除記事所需的存取權：
誰可以檢視、撰寫及刪除問題附註？
附註可讓專案成員針對特定問題發表留言、提供狀態更新等。
專案成員張貼附註時，附註會標示為 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
有時會無法準確辨識迴歸問題。我們現在使用上述慣例。
