本頁面針對使用 Crashlytics 的常見問題提供疑難排解說明和解答。如果找不到所需資訊或需要其他協助,請與 Firebase 支援團隊聯絡。
一般疑難排解/常見問題
未看到未發生當機情形的指標和/或當機風險驟升快訊
如果沒有看到未發生當機情形的指標 (例如未發生當機情形的使用者和工作階段) 和/或當機風險驟升快訊,請確認您使用的是
未顯示導覽標記記錄
如未看到導覽標記記錄,建議您檢查應用程式的 Google Analytics (分析) 設定。請確認你符合下列規定:
為什麼系統只會針對 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 v18.3.5 以上版本 (Firebase BoM v31.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
如何在 NDK 上使用我自己的 Breakpad 符號檔案產生器二進位檔?
Crashlytics 外掛程式提供自訂的 Breakpad 符號檔案產生器。如果您想使用自己的二進位檔產生 Breakpad 符號檔案 (例如,如果您想從原始碼建構所有原生執行檔),可以使用選用的 symbolGeneratorBinary
擴充功能屬性來指定執行檔路徑。
您可以透過下列任一方式指定 Breakpad 符號檔案產生器二進位檔的路徑:
方法 1:透過 build.gradle
檔案中的 firebaseCrashlytics
擴充功能指定路徑
請將以下內容加入應用程式層級的 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
為什麼會出現.kt
問題的當機事件標示為.java
問題?
如果應用程式使用的模糊處理工具不會公開副檔名,則 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 控制台中,我們會嘗試找出可能與已加上 .java
標籤的現有問題重複出現的新 .kt
問題,並向您發出通知。
誰可以檢視、撰寫及刪除問題附註?
附註可讓專案成員對問題、狀態更新等特定問題提供評論。
專案成員張貼附註時,附註會標記其 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 已重新開啟問題。如果您不希望問題因迴歸演算法而重新開啟,請「忽略」問題,而不要關閉問題。
為什麼舊版應用程式會出現迴歸問題?
如果報告是來自您在關閉問題時從未傳送任何當機報告的舊版應用程式,Crashlytics 會考量問題迴歸,並且重新開啟問題。
在下列情況中,可能會出現這種情況:您修正錯誤並發布了新版應用程式,但使用者仍使用舊版應用程式,而未修正錯誤。也許在您解決問題時,其中一個舊版本從未傳送任何當機報告,而這些使用者開始遇到該錯誤,而這些當機報告將觸發迴歸問題。
如果您不希望問題因迴歸演算法而重新開啟,請「忽略」問題,而不要關閉問題。