iOS+
Android
Flutter
Unity
このページでは、Crashlytics の使用に関するトラブルシューティングのヘルプ情報と、よくある質問への回答を紹介します。お探しの情報が見つからない場合や、サポートが必要な場合は、Firebase サポート にお問い合わせください。
一般的なトラブルシューティングとよくある質問
クラッシュの影響を受けていない指標またはベロシティ アラートが表示されない
クラッシュの影響を受けていない指標（クラッシュの影響を受けていないユーザーやセッションなど）またはベロシティ アラートが表示されない場合は、
Crashlytics SDK v18.6.0 以降（または Firebase BoM v32.6.0 以降）
を使用していることを確認してください。
パンくずリストのログが表示されない
パンくずリストのログ が表示されない場合は、Google アナリティクスに関するアプリの構成を確認することをおすすめします。次の要件を満たしていることを確認してください。
ANR が Android 11 以降でのみ報告されるのはなぜですか？
Crashlytics は、Android 11 以降を搭載したデバイスからの Android アプリの ANR レポートをサポートしています。ANR の収集に使用される基盤となる API（getHistoryProcessExitReasons ）は、SIGQUIT やウォッチドッグ ベースの方法よりも信頼性が高くなっています。この API は Android 11 以降のデバイスでのみ使用できます。
一部の ANR に BuildId がないのはなぜですか？
一部の ANR に BuildId がない場合は、次のようにトラブルシューティングを行ってください。
最新バージョンの Crashlytics Android SDK と Crashlytics Gradle プラグインを使用していることを確認します。
Android 11 ANR と一部の Android 12 ANR に BuildId がない場合は、古い SDK または古い Gradle プラグインを使用している可能性があります。これらの ANR の BuildId を適切に収集するには、次のバージョンを使用する必要があります。
Crashlytics Android SDK v18.3.5 以降（Firebase BoM v31.2.2 以降）
Crashlytics Gradle プラグイン v2.9.4 以降
共有ライブラリで標準以外の場所を使用していないか確認します。
アプリの共有ライブラリのみの BuildId がない場合は、共有ライブラリの標準のデフォルトの場所を使用していない可能性があります。その場合、Crashlytics は関連付けられている BuildId を見つけられない可能性があります。共有ライブラリには標準の場所を使用することをおすすめします。
ビルドプロセス中に BuildId がストリップされていないことを確認します。
以下のトラブルシューティングのヒントは、ANR とネイティブ コード クラッシュのいずれに対しても有効です。
バイナリに対して readelf -n を実行して、BuildId が存在するかどうかを確認します。BuildId が存在しない場合は、ビルドシステムのフラグに -Wl,--build-id を追加します。
APK サイズを縮小する際に、誤って BuildId を削除していないことを確認します。
ストリップされているライブラリ バージョンとストリップされていないライブラリ バージョンがある場合は、コードで正しいバージョンを参照するようにしてください。
Crashlytics ダッシュボードと Google Play Console での 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 拡張プロパティを使用して、実行可能ファイルへのパスを指定します。
注: Android バイナリでは、Breakpad シンボル ファイル生成ツールの Linux バージョンが必要です。 次の 2 つの方法のいずれかで、Breakpad シンボル ファイル生成ツールのバイナリへのパスを指定できます。
オプション 1 : build.gradle ファイルの firebaseCrashlytics 拡張機能を使用してパスを指定する
アプリレベルの build.gradle.kts ファイルに以下のコマンドを追加します。
Gradle プラグイン v3.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 でクラッシュが取得されない
以下の例外が表示される場合、Firebase Crashlytics SDK と互換性のないバージョンの DexGuard を使用している可能性があります。
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 の問題が表示されることがあります。その状況の詳細については、よくある質問 をご覧ください。
既存の .java の問題と重複する .kt の問題が表示されるのはなぜですか？
2021 年 12 月中旬以降、Crashlytics は Kotlin を使用するアプリケーションのサポートを改善しました。
最近まで、利用可能な難読化ツールではファイル拡張子が公開されていなかったため、Crashlytics はデフォルトで .java ファイル拡張子を使用して各問題を生成していました。Android Gradle 4.2.0 以降では、R8 でファイル拡張子がサポートされています。
今回の更新で、Crashlytics はアプリで使用される各クラスが Kotlin で記述されているかどうかを判断し、問題の署名に正しいファイル名を含めることができるようになりました。アプリが次の設定を使用している場合は、（状況に応じて）クラッシュが .kt ファイルのものであると正しく表示されるようになります。
アプリで Android Gradle 4.2.0 以降を使用している。
アプリで R8 を使用して難読化をオンにしている。
新しいクラッシュでは問題の署名に正しいファイル拡張子が含まれるため、.java のラベルが付けられた既存の問題と重複する新しい .kt の問題が表示されることがあります。Firebase コンソールでは、新しい .kt の問題が、.java のラベルが付けられた既存の問題と重複している可能性がある場合、それを識別して通知することを試みています。
問題に関するノートを表示、書き込み、削除できるのは誰ですか？
ノートを使用すると、特定の問題に関する質問やステータスの更新などについて、プロジェクト メンバーがコメントを残すことができます。
ノートには、投稿したメンバーの Google アカウントのメールアドレスがラベル付けされます。このメールアドレスは、ノートを見ることができるプロジェクト メンバー全員に対して、ノートとともに表示されます。
ノートを表示、書き込み、削除するために必要なアクセス権は次のとおりです。
問題に関するノートを表示、書き込み、削除できるのは誰ですか？
ノートを使用すると、特定の問題に関する質問やステータスの更新などについて、プロジェクト メンバーがコメントを残すことができます。
ノートには、投稿したメンバーの Google アカウントのメールアドレスがラベル付けされます。このメールアドレスは、ノートを見ることができるプロジェクト メンバー全員に対して、ノートとともに表示されます。
ノートを表示、書き込み、削除するために必要なアクセス権は次のとおりです。
インテグレーション
アプリで Google Mobile Ads SDK を使用しているが、クラッシュが取得されない
プロジェクトで Google Mobile Ads SDK と Crashlytics を併用している場合、例外ハンドラの登録時にクラッシュ レポート機能が干渉している可能性があります。この問題を解決するには、disableSDKCrashReporting を呼び出して Mobile Ads SDK でクラッシュ レポートをオフにしてください。
BigQuery データセットはどこに配置されますか？
Crashlytics を BigQuery にリンクすると、作成される新しいデータセットは、Firebase プロジェクトのロケーションに関係なく自動的に米国に配置されます。
Crashlytics は armeabi をサポートしていますか？
Firebase Crashlytics NDK は ARMv5（armeabi）をサポートしていません。この ABI のサポートは NDK r17 で削除されました。
問題の回帰
問題の回帰とは
以前にクローズした問題が再発して Crashlytics が新しいレポートを受け取った場合、その問題で回帰が発生したと言います。回帰が発生した問題は、アプリに適した方法で対応できるよう Crashlytics によって自動的に再オープンされます。
次のような場合、Crashlytics は問題を回帰として分類します。
Crashlytics が初めて、クラッシュ「A」に関するクラッシュ レポートを受け取りました。Crashlytics は、そのクラッシュに対応する問題（問題「A」）をオープンしました。
あなたはこのバグを速やかに修正し、問題「A」をクローズしてから、アプリの新しいバージョンをリリースしました。
問題をクローズにした後で、Crashlytics が問題「A」に関する別のレポートを取けとりました。
このレポートが、この問題をクローズしたときに Crashlytics で認識されていたバージョン（つまり、なんらかのクラッシュに関するレポートを送信したことがあるバージョン）のアプリから送信されたものである場合、問題は回帰と見なされません。
このレポートが、この問題をクローズしたときに Crashlytics で認識されていなかった バージョン（つまりクラッシュに関するレポートを以前に送信したことがないバージョン）のアプリから送信されたものである場合、問題は回帰と見なされて再オープンされます。
注: 2022 年 2 月以前は、問題をクローズしたときに認識されていたアプリのバージョンであるかないかに関わらず、Crashlytics は再発した問題をすべて回帰として分類していました。 問題の回帰が発生すると、回帰検出アラートが送信されます。つまり回帰シグナルを問題に追加して、Crashlytics が問題を再オープンしたことを知らせます。この回帰アルゴリズムによって問題を再オープンしたくない場合は、問題をクローズする代わりに「ミュート」します。
古いバージョンのアプリで問題の回帰が発生するのはなぜですか？
レポートを送信したアプリのバージョンが、問題をクローズした時点でクラッシュ レポートを一度も送信したことのない古いバージョンである場合、Crashlytics は問題の回帰が発生したと見なし、その問題を再オープンします。
このような状況は、バグを修正し、新しいバージョンのアプリをリリースしたにもかかわらず、バグが修正されていない古いバージョンを利用しているユーザーがいる場合に発生することがあります。問題をクローズした時点でクラッシュ レポートを一度も送信したことのない、古いバージョンのアプリがまだ使用されている場合、そのバージョンで
この回帰アルゴリズムによって問題を再オープンしたくない場合は、問題をクローズする代わりに「ミュート」します。
注: 2022 年 2 月以前は、問題をクローズしたときに認識されていたアプリのバージョンであるかないかに関わらず、Crashlytics は再発した問題をすべて回帰として分類していました。その結果、Crashlytics で回帰を正確に識別できないことがありました。そこで現在は、上記の規則が使用されています。
