このページでは、Crashlyticsの使用に関してよくある質問に対するトラブルシューティングのヘルプと回答を提供します。探しているものが見つからない場合、または追加のヘルプが必要な場合は、 Firebaseサポートにお問い合わせください。
一般的なトラブルシューティング/FAQ
クラッシュのないユーザー、ブレッドクラムログ、速度アラートが表示されない場合は、Googleアナリティクスのアプリの構成を確認することをお勧めします。
FirebaseプロジェクトでGoogleアナリティクスが有効になっていることを確認してください。
Firebaseコンソールの[統合]>[GoogleAnalytics]ページで、GoogleAnalyticsのデータ共有が有効になっていることを確認します。データ共有設定はFirebaseコンソールに表示されますが、Googleアナリティクスコンソールで管理されることに注意してください。
Firebase Crashlytics SDKに加えて、Firebase SDK for Google Analyticsがアプリに追加されていることを確認してください（ iOS + | Android ）。
すべてのFirebaseSDK（ iOS + | Android ）に最新バージョンを使用していることを確認してください。
特に、Firebase SDK for GoogleAnalyticsの少なくとも次のバージョンを使用していることを確認してください。iOS+ — v6.3.1 +（macOSおよびtvOSの場合はv8.9.0 +）| Android — v17.2.3 +（BoM v24.7.1+） 。
Crashlyticsは、Android11以降を実行するデバイスからのAndroidアプリのANRレポートをサポートします。 ANRの収集に使用する基盤となるAPI（ getHistoricalProcessExitReasons ）は、SIGQUITまたはウォッチドッグベースのアプローチよりも信頼性があります。このAPIは、Android11以降のデバイスでのみ使用できます。
GooglePlayとCrashlyticsの間でANRの数に不一致がある可能性があります。これは、ANRデータの収集と報告のメカニズムの違いによるものと予想されます。 Crashlyticsはアプリが次に起動したときにANRを報告しますが、AndroidVitalsはANRの発生後にANRデータを送信します。
さらに、CrashlyticsはAndroid 11以降を実行しているデバイスで発生するANRのみを表示します。これに対して、GooglePlayはGooglePlayサービスとデータ収集の同意が受け入れられたデバイスからのANRを表示します。
LLVMおよびGNUツールチェーンには、アプリのバイナリの読み取り専用セグメントに対して異なるデフォルトと処理があり、Firebaseコンソールで一貫性のないスタックトレースが生成される可能性があります。これを軽減するには、ビルドプロセスに次のリンカーフラグを追加します。
LLVMツールチェーンの
lldリンカーを使用している場合は、次を追加します。-Wl,--no-rosegmentGNUツールチェーンの
ld.goldリンカーを使用している場合は、次を追加します。-Wl,--rosegment
それでもスタックトレースの不整合が見られる場合（またはどちらのフラグもツールチェーンに関連していない場合）は、代わりにビルドプロセスに以下を追加してみてください。
-fno-omit-frame-pointer
Crashlyticsプラグインには、カスタマイズされたBreakpadシンボルファイルジェネレーターがバンドルされています。 Breakpadシンボルファイルの生成に独自のバイナリを使用する場合（たとえば、ビルドチェーン内のすべてのネイティブ実行可能ファイルをソースからビルドする場合）、オプションのsymbolGeneratorBinary拡張プロパティを使用して実行可能ファイルへのパスを指定します。
Breakpadシンボルファイルジェネレータバイナリへのパスは、次の2つの方法のいずれかで指定できます。
オプション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
次の例外が表示された場合は、FirebaseCrashlyticsSDKと互換性のないバージョンのDexGuardを使用している可能性があります。
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
この例外はアプリをクラッシュさせませんが、クラッシュレポートを送信することはできません。これを修正するには：
最新のDexGuard8.xリリースを使用していることを確認してください。最新バージョンには、FirebaseCrashlyticsSDKに必要なルールが含まれています。
DexGuardのバージョンを変更したくない場合は、難読化ルールに次の行を追加してみてください（DexGuard構成ファイル内）。
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
アプリがファイル拡張子を公開しない難読化ツールを使用する場合、Crashlyticsはデフォルトで.javaファイル拡張子を持つ各問題を生成します。
Crashlyticsが正しいファイル拡張子で問題を生成できるように、アプリが次の設定を使用していることを確認してください。
- AndroidGradle4.2.0以降を使用
- 難読化をオンにしてR8を使用します。アプリをR8に更新するには、このドキュメントに従ってください。
上記の設定に更新した後、既存の.javaの問題と重複する新しい.ktの問題が表示される場合があることに注意してください。その状況の詳細については、 FAQを参照してください。
2021年12月中旬から、CrashlyticsはKotlinを使用するアプリケーションのサポートを改善しました。
最近まで、利用可能な難読化ツールはファイル拡張子を公開していなかったため、Crashlyticsはデフォルトで.javaファイル拡張子を使用して各問題を生成していました。ただし、Android Gradle 4.2.0以降、R8はファイル拡張子をサポートしています。
このアップデートにより、Crashlyticsは、アプリ内で使用される各クラスがKotlinで記述されているかどうかを判断し、問題の署名に正しいファイル名を含めることができるようになりました。アプリに次の設定がある場合、クラッシュは（必要に応じて） .ktファイルに正しく起因するようになりました。
- アプリはAndroidGradle4.2.0以降を使用しています。
- アプリは、難読化がオンになっているR8を使用しています。
新しいクラッシュでは、問題の署名に正しいファイル拡張子が含まれるようになったため、実際には既存の.javaラベルの問題の単なる複製である新しい.ktの問題が表示される場合があります。 Firebaseコンソールでは、新しい.ktの問題が既存の.javaラベルの問題と重複している可能性があるかどうかを特定し、お客様に通知しようとします。
クラッシュフリーの値は、アプリを使用したものの、特定の期間にクラッシュが発生しなかったユーザーの割合を表します。
クラッシュのないユーザーの割合を計算する式は次のとおりです。その入力値はGoogleAnalyticsによって提供されます。
1 - ( CRASHED_USERS / ALL_USERS )
クラッシュが発生すると、Google Analyticsは
app_exceptionイベントタイプを送信し、 CRASHED_USERSはそのイベントタイプに関連付けられているユーザーの数を表します。ALL_USERSは、Crashlyticsダッシュボードの右上にあるドロップダウンメニューから選択した期間にアプリを使用したユーザーの総数を表します。
アナリティクスダッシュボードで、アプリのapp_exceptionイベントの数を確認できます。クラッシュの処理方法にわずかな違いがあるため、Analyticsダッシュボードに表示されるapp_exception番号は、クラッシュのないユーザーの計算で使用される番号と異なる場合があることに注意してください。
クラッシュのないユーザーの割合は、平均ではなく、時間の経過に伴う集計です。
たとえば、アプリに3人のユーザーがいるとします。これらをユーザーA、ユーザーB、ユーザーCと呼びます。次の表は、毎日アプリを使用しているユーザーと、その日にクラッシュしたユーザーを示しています。
| 月曜日 | 火曜日 | 水曜日 | |
|---|---|---|---|
| アプリを利用したユーザー | A、B、C | A、B、C | A、B |
| クラッシュしたユーザー | C | B | A |
水曜日のクラッシュフリーユーザーの割合は50％です（2人に1人のユーザーがクラッシュフリーでした）。
水曜日に2人のユーザーがアプリを使用しましたが、クラッシュが発生しなかったのは1人（ユーザーB）のみでした。過去2日間で、クラッシュのないユーザーの割合は33.3％です（3人に1人のユーザーがクラッシュしませんでした）。
過去2日間に3人のユーザーがアプリを使用しましたが、クラッシュが発生しなかったのは1人（ユーザーC）のみでした。過去3日間、クラッシュのないユーザーの割合は0％です（3人のユーザーのうち0人がクラッシュのない状態でした）。
過去3日間に3人のユーザーがアプリを使用しましたが、クラッシュは発生していません。
統合
プロジェクトでCrashlyticsをGoogleMobileAds SDKと一緒に使用している場合、例外ハンドラーの登録時にクラッシュレポーターが干渉している可能性があります。この問題を修正するには、disableSDKCrashReportingを呼び出して、 disableSDKCrashReportingのクラッシュレポートをオフにします。
CrashlyticsをBigQueryにリンクすると、Firebaseプロジェクトの場所に関係なく、作成した新しいデータセットが自動的に米国に配置されます。
プラットフォームのサポート
Firebase Crashlytics NDKはARMv5（armeabi）をサポートしていません。このABIのサポートは、NDKr17で削除されました。
退行した問題
以前に問題をクローズしたときに問題にリグレッションが発生しましたが、Crashlyticsは問題が再発したという新しいレポートを取得します。 Crashlyticsは、これらのリグレッションされた問題を自動的に再度開き、アプリに応じて適切に対処できるようにします。
Crashlyticsが問題をリグレッションとして分類する方法を説明するシナリオの例を次に示します。
- 初めて、Crashlyticsはクラッシュ「A」に関するクラッシュレポートを取得します。 Crashlyticsは、そのクラッシュに対応する問題を開きます（問題「A」）。
- このバグをすばやく修正し、問題「A」を閉じてから、アプリの新しいバージョンをリリースします。
- 問題をクローズした後、Crashlyticsは問題「A」に関する別のレポートを取得します。
- レポートが、問題を閉じたときにCrashlyticsが知っていたアプリバージョンからのものである場合（つまり、バージョンがクラッシュのクラッシュレポートを送信した場合）、Crashlyticsは問題がリグレッションされたとは見なしません。問題は解決されたままになります。
- レポートが、問題を閉じたときにCrashlyticsが認識していなかったアプリバージョンからのものである場合（つまり、バージョンがクラッシュのクラッシュレポートをまったく送信していなかった場合）、Crashlyticsは問題がリグレッションを起こしていると見なし、問題を再度開きます。 。
問題がリグレッションを起こすと、リグレッション検出アラートを送信し、リグレッションシグナルを問題に追加して、Crashlyticsが問題を再開したことを通知します。回帰アルゴリズムのために問題を再開したくない場合は、問題を閉じるのではなく「ミュート」します。
レポートが、問題を閉じたときにクラッシュレポートをまったく送信していなかった古いアプリバージョンからのものである場合、Crashlyticsは問題がリグレッションを起こしていると見なし、問題を再度開きます。
この状況は、次の状況で発生する可能性があります。バグを修正してアプリの新しいバージョンをリリースしたが、バグ修正が行われていない古いバージョンのユーザーがまだいる。偶然にも、問題を閉じたときにこれらの古いバージョンの1つがクラッシュレポートをまったく送信せず、それらのユーザーがバグに遭遇し始めた場合、それらのクラッシュレポートはリグレッションされた問題をトリガーします。
回帰アルゴリズムのために問題を再開したくない場合は、問題を閉じるのではなく「ミュート」します。