このページでは、Crashlytics の使用に関するトラブルシューティングのヘルプ情報と、よくある質問への回答を紹介します。お探しの情報が見つからない場合や、サポートが必要な場合は、Firebase サポートにお問い合わせください。
一般的なトラブルシューティングとよくある質問
クラッシュの影響を受けていないユーザー、パンくずリストのログ、ベロシティ アラートが表示されない
クラッシュの影響を受けていないユーザー、パンくずリストのログ、ベロシティ アラートが表示されない場合は、Google アナリティクスに関するアプリの構成を確認することをおすすめします。
Firebase プロジェクトで Google アナリティクスが有効になっていることを確認します。
Firebase コンソールの [統合] > [Google アナリティクス] ページで Google アナリティクスのデータ共有が有効になっていることを確認します。データ共有の設定は Firebase コンソールに表示されますが、管理は Google アナリティクス コンソールで行います。
Firebase Crashlytics SDK に加えて、Google アナリティクス用の Firebase SDK がアプリに追加されていることを確認します（iOS+ | Android）。
すべての Firebase SDK で最新バージョンを使用していることを確認します（iOS+ | Android）。
重要: 次のバージョンの Google アナリティクス用 Firebase SDK を使用していることを確認します。iOS+ — v6.3.1 以降 （macOS および tvOS の場合は v8.9.0 以降）|Android — v17.2.3 以降 （BoM v24.7.1 以降）
[問題] テーブルの中の一部の問題でさまざまな形式（場合によっては「バリアント」）が表示される
Firebase コンソールの [問題] テーブルに一覧表示される問題には、2 つの異なる形式があります。また、問題内に「バリアント」と呼ばれる特徴が存在する場合もあります。その理由を説明します。
2023 年初頭、Google はイベントをグループ化するための向上した分析エンジンをリリースしました。このリリースでは、設計の更新が行われ、新しい問題向けの高度な機能（バリアントなど）が含まれています。詳しくは、最近のブログ投稿をご覧ください。最新情報については以下からもご確認いただけます。
Crashlytics は、アプリのすべてのイベント（クラッシュ、致命的でないイベント、ANR など）を分析し、問題と呼ばれるイベントのグループを作成します。一つの問題の中のすべてのイベントには共通の障害点があります。
イベントを問題としてグループ化するために、向上した分析エンジンでは、スタック トレース内のフレーム、例外メッセージ、エラーコード、その他のプラットフォームまたはエラータイプの特性など、イベントの多くの要素を確認するようになりました。
ただし、このようにグループ化されたイベントの中には、障害に至るまでのスタック トレースが異なるものが含まれることがあります。スタック トレースが異なる場合は、根本原因が異なる可能性があります。一つの問題の中のこの違いを表現するため、問題の中にバリアントが作成されるようになりました。個々のバリアントは、一つの問題の中に含まれ、同じ障害点と類似のスタック トレースを持つイベントのサブグループです。バリアントによって、問題の中の最も一般的なスタック トレースをデバッグし、異なる根本原因によって障害が発生しているかどうかを判断できます。
改良点は以下のとおりです。
[問題] の行に表示されるメタデータを改善
アプリで問題を簡単に把握し、優先順位を設定できるようになりました。問題の重複の低減
行番号を変更しても新しい問題は発生しません。さまざまな根本原因による複雑な問題のデバッグが容易に
バリアントを使用して、問題内で最も一般的なスタック トレースをデバッグできます。より有意義なアラートとシグナル
新しい問題は実際の新しいバグを表すようになりました。検索機能の強化
それぞれの問題に、例外タイプやパッケージ名など、検索可能なメタデータが追加されました。
改良された機能の提供の詳細は次のとおりです。
アプリから新しいイベントを受け取ると、既存の問題と一致するかどうかが確認されます。
一致するものがない場合は、よりスマートなイベント グループ アルゴリズムをイベントに自動的に適用し、改良されたメタデータ設計を使って新しい問題を作成します。
これは、イベントのグループ分けに関する最初の大きなアップデートです。フィードバックがある場合や問題が発生した場合は、レポートに記入してお知らせください。
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 コンソールで一貫性のないスタック トレースが生成される可能性があります。この問題を軽減するには、次のリンカーフラグをビルドプロセスに追加します。
LLVM ツールチェーンの
lldリンカーを使用している場合は、次のリンカーフラグを追加します。-Wl,--no-rosegmentGNU ツールチェーンの
ld.goldリンカーを使用している場合は、次のリンカーフラグを追加します。-Wl,--rosegment
スタック トレースの不整合がまだ発生している場合（またはどちらのフラグもお使いのツールチェーンに関連していない場合）は、代わりに次のリンカーフラグをビルドプロセスに追加してみてください。
-fno-omit-frame-pointer
NDK に独自の Breakpad シンボル ファイル生成ツールのバイナリを使用するにはどうすればよいですか？
Crashlytics プラグインは、カスタマイズされた Breakpad シンボル ファイル生成ツールをバンドルします。Breakpad シンボル ファイルの生成に独自のバイナリを使用する場合は（たとえば、ビルドチェーン内のすべてのネイティブの実行可能ファイルをソースからビルドする場合）、オプションの symbolGeneratorBinary 拡張プロパティを使用して、実行可能ファイルへのパスを指定します。
次の 2 つの方法のいずれかで、Breakpad シンボル ファイル生成ツールのバイナリへのパスを指定できます。
オプション 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
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 アナリティクスから提供されます。
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100
クラッシュが発生すると、Google アナリティクスは
app_exceptionイベントタイプを送信します。CRASHED_USERS はそのイベントタイプに関連付けられているユーザーの数を表します。ALL_USERS は、Crashlytics ダッシュボードの右上にあるプルダウン メニューから選択した期間中にアプリを利用したユーザーの合計数を表します。
クラッシュの影響を受けていないユーザーの割合は、時間の経過に伴う集計です。平均ではありません。
たとえば、アプリに 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 人の中にクラッシュの影響を受けなかったユーザーはいませんでした）。
過去 3 日間にアプリを利用したユーザーは 3 人でしたが、クラッシュが発生しなかったユーザーはいませんでした。
問題に関するノートを表示、書き込み、削除できるのは誰ですか？
ノートを使用すると、特定の問題に関する質問やステータスの更新などについて、プロジェクト メンバーがコメントを残すことができます。
ノートには、投稿したメンバーの Google アカウントのメールアドレスがラベル付けされます。このメールアドレスは、ノートを見ることができるプロジェクト メンバー全員に対して、ノートとともに表示されます。
ノートを表示、書き込み、削除するために必要なアクセス権は次のとおりです。
次のいずれかのロールを持つプロジェクト メンバーは、問題に関する既存のノートの表示と削除、新しいノートの書き込みを行うことができます。
次のいずれかのロールを持つプロジェクト メンバーは、問題に関するノートを見ることはできますが、ノートの削除や書き込みはできません。
- プロジェクトの閲覧者、Firebase 閲覧者、品質閲覧者、Crashlytics 閲覧者
インテグレーション
アプリで 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 で認識されていなかったバージョン（つまりクラッシュに関するレポートを以前に送信したことがないバージョン）のアプリから送信されたものである場合、問題は回帰と見なされて再オープンされます。
問題の回帰が発生すると、回帰検出アラートが送信されます。つまり回帰シグナルを問題に追加して、Crashlytics が問題を再オープンしたことを知らせます。この回帰アルゴリズムによって問題を再オープンしたくない場合は、問題をクローズする代わりに「ミュート」します。
古いバージョンのアプリで問題の回帰が発生するのはなぜですか？
レポートを送信したアプリのバージョンが、問題をクローズした時点でクラッシュ レポートを一度も送信したことのない古いバージョンである場合、Crashlytics は問題の回帰が発生したと見なし、その問題を再オープンします。
このような状況は、バグを修正し、新しいバージョンのアプリをリリースしたにもかかわらず、バグが修正されていない古いバージョンを利用しているユーザーがいる場合に発生することがあります。問題をクローズした時点でクラッシュ レポートを一度も送信したことのない、古いバージョンのアプリがまだ使用されている場合、そのバージョンでバグが発生してクラッシュ レポートが送信されると、問題の回帰がトリガーされます。
この回帰アルゴリズムによって問題を再オープンしたくない場合は、問題をクローズする代わりに「ミュート」します。