本頁面提供 Crashlytics 的疑難排解說明和常見問題解答。如果找不到所需資訊或需要其他協助，請與 Firebase 支援團隊 聯絡。
本頁面提供下列主題的相關資訊：
一般疑難排解/常見問題
未看到導覽標記記錄
如果沒有看到路徑記錄 (iOS+ |
Android |
Flutter |
Unity )，
建議檢查應用程式的 Google Analytics 設定。
請確認符合下列規定：
您已在 Firebase 專案中啟用Google Analytics 。
您已為「Google Analytics 」啟用「資料共用」管理 Analytics 資料共用設定 」一文。
您已將 Firebase SDK 新增至應用程式：Google Analytics
iOS+ |
Android |
Flutter |
Unity 。
必須 在 Crashlytics SDK 之外新增這個 SDK。
您在應用程式中使用的所有產品，都採用最新版 Firebase SDK
(iOS+ |
Android |
Flutter |
Unity )。
如果是 Apple 平台和 Android 應用程式，請特別確認您至少 使用下列版本的 Firebase SDK for Google Analytics ：iOS+ - v6.3.1 以上版本Android - v17.2.3 以上版本(BoM v24.7.1 以上版本) 。
未收到當機風險驟升警告
如果沒有看到速度快訊，請確認您使用的是
未看到未發生當機情形的指標 (或看到不可靠的指標)
如果沒有看到未發生當機情形的指標 (例如未發生當機情形的使用者和工作階段)，或是看到不可靠的指標，請檢查下列事項：
誰可以查看、撰寫及刪除問題的附註？
專案成員可以在附註中針對特定問題留言，提出疑問或更新狀態等。
專案成員發布附註時，系統會標示他們的 Google 帳戶電子郵件地址。所有有權查看附註的專案成員，都會看到這個電子郵件地址和附註。
以下說明查看、撰寫及刪除記事所需的存取權：
什麼是回歸問題？
如果問題先前已結案，但Crashlytics 收到問題再次發生的新報告，就會視為「迴歸」問題。Crashlytics 會自動重新開啟這些回歸問題，方便您視應用程式情況解決問題。
以下範例情境說明 Crashlytics 如何將問題歸類為迴歸：
Crashlytics 首次收到有關「Crash A」的當機報告。Crashlytics 會開啟該當機問題的對應問題 (問題「A」)。您迅速修正這個錯誤、關閉「A」問題，然後發布新版應用程式。
Crashlytics 在您關閉問題後，收到有關問題「A」的另一份報告。
如果報告來自應用程式版本，而您關閉問題時Crashlytics 知道 該版本 (表示該版本已針對任何 當機情況傳送當機報告)，則 Crashlytics 不會將該問題視為回歸。問題將維持關閉狀態。
如果報告來自應用程式版本，而該版本在您關閉問題時「不知道」Crashlytics Crashlytics 會將問題視為迴歸，並重新開啟問題。
注意： 2022 年 2 月前，如果問題在任何 應用程式版本中再次發生，Crashlytics 就會將問題歸類為回歸，即使是您關閉問題時我們已知的應用程式版本也一樣。這導致Crashlytics 有時會誤判迴歸。我們現在使用上述慣例。 如果問題復發，系統會傳送迴歸偵測警報，並在問題中新增迴歸信號，通知您 Crashlytics 已重新開啟問題。如果不想讓問題因迴歸演算法而重新開啟，請「將問題設為靜音」，而非關閉問題。
為什麼舊版應用程式會出現回歸問題？
如果報表來自舊版應用程式，且您關閉問題時，該版本從未傳送任何當機報告，則 Crashlytics 會將問題視為迴歸問題，並重新開啟問題。
如果發生下列情況，就可能出現這種情形：您已修正錯誤並發布新版應用程式，但仍有使用者使用舊版應用程式，因此無法獲得錯誤修正。如果先前某個版本在您關閉問題時從未 傳送任何當機報告，而這些使用者開始遇到錯誤，則這些當機報告會觸發回歸問題。
如果不想讓問題因迴歸演算法而重新開啟，請「靜音」問題，而非關閉問題。
注意： 2022 年 2 月前，如果問題在任何應用程式版本中再次發生，Crashlytics 都會將問題歸類為「迴歸」，即使是您關閉問題時已知的應用程式版本也一樣。這導致系統有時會誤判迴歸。Crashlytics 我們現在使用上述慣例。
以下各節提供平台專屬的疑難排解和常見問題支援：
iOS+ |
Android |
Unity 。
缺少 dSYM 或未上傳 dSYM
如要上傳專案的 dSYM 並取得詳細輸出內容，請檢查下列項目：
請確認專案的建構階段包含 Crashlytics 執行指令碼，這樣 Xcode 就能在建構時上傳專案的 dSYM (如需新增指令碼的說明，請參閱「初始化 Crashlytics 」)。更新專案後，請強制當機 ，並確認當機情形會顯示在 Crashlytics 資訊主頁中。
如果 Firebase 控制台中顯示「缺少 dSYM」快訊，請檢查 Xcode，確認是否正確產生建構版本的 dSYM 。
如果 Xcode 正確產生 dSYM，但您仍看到 dSYM 遺失，可能是執行指令碼工具在上傳 dSYM 時發生問題。如果發生這種情況，請嘗試下列方法：
確認你使用的是最新版 Crashlytics 。
手動上傳缺少的 dSYM 檔案：
如果 dSYM 仍持續遺失或上傳失敗，請與 Firebase 支援團隊 聯絡，並附上記錄檔。
當機情形的符號化效果不佳
如果堆疊追蹤記錄的符號化效果不佳，請檢查下列事項：
如果應用程式程式庫中的影格缺少對應用程式程式碼的參照，請確認 -fomit-frame-pointer
如果應用程式的程式庫出現多個 (Missing) 影格，請檢查Crashlytics 「dSYM」分頁Firebase 控制台，看看是否有列出缺少的選用 dSYM (適用於受影響的應用程式版本)。如果是，請按照本頁面「缺少 dSYM 警示」
的缺少/未上傳 dSYM 常見問題 疑難排解步驟操作。請注意，上傳這些 dSYM 無法對已 發生的異常終止進行符號化，但有助於確保未來 的異常終止事件能順利符號化。
為什麼系統只會回報 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 的 BuildId，以及部分 Android 12 的 ANR，則可能是因為您使用的 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 是否存在。如果沒有，請將 -Wl,--build-id 新增至建構系統的標記。BuildId
確認您並非為了縮減 APK 大小，而無意間移除 BuildId。
如果您同時保留程式庫的已剝除和未剝除版本，請務必在程式碼中指向正確的版本。
Crashlytics 資訊主頁和 Google Play 管理中心的 ANR 報告差異
Google Play 和 Crashlytics 的 ANR 數量可能不一致。這是預期中的情況，因為收集和回報 ANR 資料的機制不同。Crashlytics 會在應用程式下次啟動時回報 ANR，而 Android Vitals 則會在發生 ANR 後傳送相關資料。
此外，Crashlytics 只會顯示在 Android 11 以上版本裝置上發生的 ANR，而 Google Play 則會顯示在接受 Google Play 服務和資料收集同意聲明的裝置上發生的 ANR。
為什麼我會看到來自標示為 .java 問題的 .kt 檔案的當機情形？
如果應用程式使用的模糊處理器不會公開副檔名，Crashlytics 預設會為每個問題產生 .java 副檔名。
為確保 Crashlytics 能產生副檔名正確的問題，請確認應用程式使用下列設定：
使用 Android Gradle 4.2.0 以上版本
使用 R8，並開啟模糊化功能。如要將應用程式更新至 R8，請參閱這份文件 。
請注意，更新為上述設定後，您可能會開始看到新的 .kt 問題，這些問題與現有的 .java 問題重複。如要進一步瞭解這種情況，請參閱常見問題 。
為什麼我會看到與現有 .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 標籤問題重複，我們會嘗試識別並通知您。
使用 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
如何升級至 Crashlytics Gradle 外掛程式第 3 版？
最新版 Crashlytics Gradle 外掛程式是主要版本 (3.0.0 版)，並淘汰對較舊版 Gradle 和 Android Gradle 外掛程式的支援，讓 SDK 更加現代化。此外，這個版本中的變更也解決了 AGP v8.1 以上版本的問題，並改善了對原生應用程式和自訂建構作業的支援。
基本規定
Crashlytics Gradle 外掛程式 v3 的最低需求如下：
Kotlin
plugins {
id ( "com.android.application" ) version "8.1.4 " apply false
id ( "com.google.gms.google-services" ) version "4.4.4 " apply false
...
} Groovy
plugins {
id 'com.android.application' version '8.1.4 ' apply false
id 'com.google.gms.google-services' version '4.4.4 ' apply false
...
}
「Crashlytics 」擴充功能異動
使用第 3 版 Crashlytics Gradle 外掛程式時，Crashlytics 擴充功能會出現下列重大變更：
已從 defaultConfig android 區塊中移除擴充功能。請改為設定每個變體。
移除已淘汰的 mappingFile 欄位。系統現在會自動提供合併的對應檔案。
移除已淘汰的 strippedNativeLibsDir 欄位。請改用 unstrippedNativeLibsDir 處理所有原生程式庫。
將「unstrippedNativeLibsDir」欄位變更為累計。
查看多個目錄的範例
buildTypes {
release {
configure<CrashlyticsExtension> {
nativeSymbolUploadEnabled = true
unstrippedNativeLibsDir = file ( "MY/NATIVE/LIBS " )
}
}
productFlavors {
flavorDimensions += "feature"
create ( "basic" ) {
dimension = "feature"
// ...
}
create ( "featureX" ) {
dimension = "feature"
configure<CrashlyticsExtension> {
unstrippedNativeLibsDir = file ( "MY/FEATURE_X/LIBS " )
}
}
}
}
uploadCrashlyticsSymbolFilesBasicReleaseMY/NATIVE/LIBS uploadCrashlyticsSymbolFilesFeatureXReleaseMY/NATIVE/LIBS MY/FEATURE_X/LIBS
將結尾欄位 symbolGenerator 替換為兩個新的頂層欄位：
symbolGeneratorType，字串可以是 "breakpad" (預設) 或 "csym"。breakpadBinary，本機二進位覆寫的檔案。dump_syms
如何升級擴充功能範例
Kotlin
之前
buildTypes {
release {
configure<CrashlyticsExtension> {
// ...
symbolGenerator (
closureOf<SymbolGenerator> {
symbolGeneratorType = "breakpad"
breakpadBinary = file ( "/PATH/TO/BREAKPAD/DUMP_SYMS " )
}
)
}
}
}
現已推出第 3 版
buildTypes {
release {
configure<CrashlyticsExtension> {
// ...
symbolGeneratorType = "breakpad"
breakpadBinary = file ( "/PATH/TO/BREAKPAD/DUMP_SYMS " )
}
}
}
Groovy
之前
buildTypes {
release {
firebaseCrashlytics {
// ...
symbolGenerator {
breakpad {
binary file ( "/PATH/TO/BREAKPAD/DUMP_SYMS " )
}
}
}
}
}
現已推出第 3 版
buildTypes {
release {
firebaseCrashlytics {
// ...
symbolGeneratorType "breakpad"
breakpadBinary file ( "/PATH/TO/BREAKPAD/DUMP_SYMS " )
}
}
}
Crashlytics 資訊主頁和 logcat 中的 NDK 堆疊追蹤記錄差異
LLVM 和 GNU 工具鍊對應用程式二進位檔的唯讀區隔有不同的預設值和處理方式，可能會在 Firebase 控制台中產生不一致的堆疊追蹤記錄。如要解決這個問題，請在建構程序中加入下列連結器標記：
如果堆疊追蹤仍不一致 (或兩個標記都不適用於工具鍊)，請改為在建構程序中加入下列項目：
-fno-omit-frame-pointer
如何使用自己的 Breakpad 符號檔案產生器二進位檔，搭配 NDK 進行偵錯？
Crashlytics 外掛程式會將自訂的 Breakpad 符號檔產生器 設為套件。如果您偏好使用自己的二進位檔產生 Breakpad 符號檔 (例如，您偏好從來源建構建構鏈中的所有原生可執行檔)，請使用選用的 symbolGeneratorBinary 擴充功能屬性，指定可執行檔的路徑。
注意： Android 二進位檔必須使用 Linux 版的 Breakpad 符號檔案產生器。 您可以透過下列兩種方式指定 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
Crashlytics 是否支援 armeabi？
Firebase Crashlytics NDK 不支援 ARMv5 (armeabi)。NDK r17 以上版本已不再支援這個 ABI。
在 Crashlytics 資訊主頁中看到 Android 應用程式的未符號化堆疊追蹤記錄
如果您使用 Unity IL2CPP ，且看到未符號化的堆疊追蹤記錄，請嘗試下列做法：
請務必使用 Crashlytics Unity SDK 8.6.1 以上版本。
請確認您已設定並執行 Firebase CLI crashlytics:symbols:upload 指令，產生及上傳符號檔案。
每次建立發布版本或任何建構版本時，您都需要執行這個 CLI 指令，才能在 Firebase 控制台中查看符號化的堆疊追蹤記錄。詳情請參閱「取得可讀取的當機報告 」。
是否可搭配使用 IL2CPP 的應用程式使用 Crashlytics ？
可以，Crashlytics 可顯示使用 IL2CPP 的應用程式符號化堆疊追蹤記錄。這項功能適用於在 Android 或 Apple 平台上發布的應用程式。請採取以下行動：
確認您使用的是 Crashlytics Unity SDK 8.6.0 以上版本。
請完成所用平台適用的必要工作：
Apple 平台應用程式 ：不需要採取任何特別行動。如果是 Apple 平台應用程式，Firebase Unity 編輯器外掛程式會自動設定 Xcode 專案，以便上傳符號。
Android 應用程式 ：請確認您已設定並執行 Firebase CLI crashlytics:symbols:upload 指令，產生及上傳符號檔。
每次建立發布版本或任何建構版本時，您都需要執行這個 CLI 指令，才能在 Firebase 控制台中查看符號化的堆疊追蹤記錄。詳情請參閱「取得可讀取的當機報告 」。
將未偵測到的例外狀況回報為嚴重錯誤
Crashlytics 可以將未偵測到的例外狀況回報為嚴重事件 (從 Unity SDK 的 10.4.0 版 開始)。以下常見問題說明使用這項功能的理由和最佳做法。
為什麼應用程式應將未偵測到的例外狀況回報為嚴重錯誤？
將未偵測到的例外狀況回報為嚴重錯誤，可更如實地指出哪些例外狀況可能導致遊戲無法執行，即使應用程式持續運作也一樣。
請注意，開始回報嚴重錯誤後，無當機使用者 (CFU) 百分比可能會降低，但 CFU 指標會更貼近使用者體驗。
重要事項： 將未處理的例外狀況回報為嚴重錯誤，不會 Android Vitals 。Crashlytics 中回報的嚴重錯誤只會顯示給您，方便您找出並修正應用程式和遊戲中的問題。
哪些例外狀況會回報為嚴重錯誤？
如要讓 Crashlytics 將未偵測到的例外狀況回報為嚴重事件，必須符合下列兩項條件：
啟用將未偵測到的例外狀況回報為嚴重事件後，我現在有許多新的嚴重事件。如何正確處理這些例外狀況？
當您開始收到未處理例外狀況的報告 (視為嚴重錯誤)，可以採取下列幾種方式處理這些未處理的例外狀況：
攔截並處理擲回的例外狀況 系統會建立並擲回例外狀況，反映非預期或例外狀態 。如要解決例外狀況反映的問題，必須將程式還原至已知狀態 (這個程序稱為例外狀況處理
除非程式無法返回已知狀態，否則最佳做法是擷取並處理所有 預期的例外狀況。
如要控管哪些類型的例外狀況會由哪些程式碼擷取及處理，請將可能產生例外狀況的程式碼包裝在 try-catch 區塊中 。請確保 catch 陳述式中的條件盡可能嚴格，以便適當處理特定例外狀況。
在 Unity 或 Crashlytics 中記錄例外狀況您可以在 Unity 或 Crashlytics 中記錄例外狀況，協助偵錯問題。
使用 Crashlytics 時，最常見且建議的兩種做法如下：
不過，如要手動向 Unity Cloud Diagnostics 回報嚴重事件，可以使用 Debug.LogException。這個選項會將例外狀況列印到 Unity 控制台 (如選項 1)，但也會擲回例外狀況 (無論是否已擲回或擷取)。系統會擲回非本機錯誤。也就是說，即使是包含 Debug.LogException(exception)
try-catch 區塊的周圍，仍會導致未擷取的例外狀況。
因此，只有在您想同時 Debug.LogException：
將例外狀況列印到 Unity 控制台。
將例外狀況上傳至 Crashlytics 做為嚴重事件。
擲回例外狀況，將其視為未捕捉到的 例外狀況，並回報給 Unity Cloud Diagnostics。
請注意，如要將偵測到的例外狀況列印到 Unity 控制台 並 Crashlytics 做為非嚴重事件，請改為執行下列操作：
try
{
methodThatThrowsMyCustomExceptionType ();
}
catch ( MyCustomExceptionType exception )
{
// Print the exception to the Unity console at the error level.
Debug . LogError ( exception );
// Upload the exception to Crashlytics as a non-fatal event.
Crashlytics . LogException ( exception ); // not Debug.LogException
//
// Code that handles the exception
//
}
整合支援
應用程式也使用 Google Mobile Ads SDK，但不會當機
如果您的專案同時使用 Crashlytics 和 Google Mobile Ads SDK，當機報告器很可能在註冊例外狀況處理常式時發生干擾。如要修正這個問題，請呼叫 disableSDKCrashReporting，在 Mobile Ads SDK 中關閉當機報告功能。
我的 BigQuery 資料集位於何處？
Firebase 會將資料匯出至您設定資料匯出至 BigQuery 時選取的資料集位置。
這個位置會同時套用到 Crashlytics 資料集和 Firebase 工作階段資料集 (如果已啟用匯出工作階段資料)。
這個位置僅適用於匯出至 BigQuery 的資料，不會影響儲存資料的位置，以供在 Firebase 控制台的 Crashlytics 資訊主頁或 Android Studio 中使用。
資料集建立後，該資料集的位置就無法再變更，不過您可以將資料集複製到其他位置，或將資料集手動移動 (重新建立) 至其他位置。詳情請參閱「變更現有匯出作業的位置 」。
注意： 只有在 2024 年 10 月中旬後啟用匯出功能，或是升級至新的匯出基礎架構 ，才能選取及變更資料匯出位置。
如何升級至 BigQuery 的新匯出基礎架構？
2024 年 10 月中旬，Crashlytics 推出了新基礎架構，可批次 將 Crashlytics 資料匯出至 BigQuery 。
所有 Firebase 專案最快將於 2026 年 1 月 9 日自動升級至新的批次匯出基礎架構。
您可以在這個日期前升級 ，但請確認 BigQuery 批次資料表符合升級的必要條件 。
您可以升級 至新版基礎架構，但請確認批次資料表符合升級的先決條件 。BigQuery
注意： 這項基礎架構升級僅適用於 Crashlytics 批次 匯出，不 適用於工作階段匯出。 判斷是否使用新基礎架構
如果您在 2024 年 10 月中旬以後啟用批次匯出功能，Firebase 專案就會自動使用新的匯出基礎架構。
如要查看專案使用的基礎架構，請前往 Google Cloud 控制台，如果「資料移轉設定」Firebase Crashlytics with Multi-Region Support，則專案使用新的匯出基礎架構。
舊版和新版匯出基礎架構的重要差異
步驟 1 ：升級的必要條件
確認現有BigQuery 批次資料表的 ID 與Firebase 專案中已註冊 Firebase 應用程式設有的軟體包 ID 或套件名稱相符 。 如果不符，匯出的批次資料可能會中斷。大多數專案都會處於適當且相容的狀態，但升級前請務必檢查。
注意： 結尾為 REALTIME 的 BigQuery 串流資料表不受新匯出基礎架構影響，可以忽略。 舉例來說，以下是升級時不會發生任何問題的理想狀態：
您有一個名為 com_yourcompany_yourproject_IOS 的批次資料表，以及在 Firebase 專案中註冊的 Firebase iOS+ 應用程式，軟體包 ID 為 com.yourcompany.yourproject。
您有一個名為「com_yourcompany_yourproject_ANDROID」的批次資料表，以及在 Firebase 專案中註冊的 Firebase Android 應用程式，套件名稱為「com.yourcompany.yourproject」。
如果批次資料表名稱不 符合已註冊 Firebase 應用程式的 ID，請在手動升級前或 2026 年 1 月 9 日前按照本頁稍後的說明 操作，以免批次匯出作業中斷。
步驟 2 ：手動升級至新基礎架構如果您在 2024 年 10 月中旬前 Firebase 控制台中切換 Crashlytics 資料匯出功能，先關閉再開啟，即可手動升級至新基礎架構。
詳細步驟如下：
前往 Firebase 控制台的「整合」
在 BigQuery 資訊卡中，按一下「管理」
將 Crashlytics 滑桿切換為關閉，即可停用匯出功能。按照提示確認要停止資料匯出。
立即再次開啟 Crashlytics 滑桿，重新啟用匯出功能。
系統顯示提示時，請確認要匯出資料。
您現在使用新的匯出基礎架構，將 Crashlytics 資料匯出至 BigQuery 。
現有批次資料表名稱與 Firebase 應用程式 ID 不符
如果現有批次資料表名稱不 符合已註冊 Firebase 應用程式的軟體包 ID 或套件名稱，請展開這個部分，並實作其中一個選項，以免匯出的批次資料中斷。
如果現有批次資料表處於這種狀態，表示這些資料表與 Firebase 的新批次匯出至 BigQuery 基礎架構不相容。BigQuery 請注意，所有 Firebase 專案最快將於 2026 年 1 月 9 日自動遷移至新的匯出基礎架構。
請按照本節的指引操作，在手動升級前或 2026 年 1 月 9 日前 Crashlytics 資料批次匯出至 BigQuery 時發生中斷。
跳至相關操作說明，瞭解如何避免服務中斷
瞭解匯出基礎架構如何使用 ID 將資料寫入 BigQuery 資料表
以下說明這兩種匯出基礎架構如何將 Crashlytics 資料寫入BigQuery 批次資料表：
很抱歉，有時應用程式二進位檔中的軟體包 ID 或套件名稱 ，與Firebase 專案中已註冊 Firebase 應用程式的軟體包 ID 或套件名稱 不符。如果有人在註冊應用程式時未輸入實際 ID，通常就會發生這種情況。
如果未在升級前修正這個問題，會發生什麼情況？
如果這兩個位置的 ID 不相符，升級至新的匯出基礎架構後會發生下列情況：
識別碼不符的情境範例
請注意，BigQuery 批次資料表名稱會自動附加 _IOS 或 _ANDROID，指出應用程式的平台。
應用程式二進位檔中的 ID
為 Firebase 應用程式設定的 ID
舊版行為
升級至新匯出基礎架構後的行為
解決方案
foobar
寫入以應用程式二進位檔 (foo) 中的 ID 命名的單一 資料表
建立並寫入以 Firebase 應用程式設定的 ID (bar) 命名的單一 資料表。
請實作下列選項 1 或 2。
foobar、qux 等
寫入以應用程式二進位檔 (foo) 中的 ID 命名的單一 資料表
建立*，然後寫入以 Firebase 應用程式設定的 ID 命名的多個 資料表 (bar、qux 等)
實作下文所述的選項 2。
foo、baz 等bar
寫入以應用程式二進位檔中的多個 ID 命名的多個 資料表 (foo、baz 等)
建立**，然後將每個應用程式的資料寫入以 Firebase 應用程式 (bar) 設定的 ID 命名的單一 資料表
無法實作任何選項。
您仍可使用應用程式的 bundle_identifier (與資料一併匯出)，在單一資料表中區分各個應用程式的資料。
* 如果應用程式二進位檔中的 ID 與 Firebase 應用程式設定的 ID 相符，新的匯出基礎架構就不會為該 ID 建立新資料表。而是繼續將該特定應用程式的資料寫入其中。所有其他應用程式都會寫入新資料表。
** 如果應用程式二進位檔中的某個 ID 與 Firebase 應用程式的 ID 集相符，新的匯出基礎架構就不會建立新資料表。而是會維護該資料表，並開始將所有應用程式的資料寫入其中。
避免中斷的選項
為避免服務中斷，請在手動升級前 或 2026 年 1 月 9 日前 ，按照下方其中一個選項的指示操作。
