Crashlytics についてのトラブルシューティングとよくある質問

[問題] テーブルの中の一部の問題でさまざまな形式（場合によっては「バリアント」）が表示される

Firebase コンソールの [問題] テーブルに一覧表示される問題には、2 つの異なる形式があります。また、問題内に「バリアント」と呼ばれる特徴が存在する場合もあります。その理由を説明します。

2023 年初頭、Google はイベントをグループ化するための向上した分析エンジンをリリースしました。このリリースでは、設計の更新が行われ、新しい問題向けの高度な機能（バリアントなど）が含まれています。詳しくは、最近のブログ投稿をご覧ください。最新情報については以下からもご確認いただけます。

Crashlytics は、アプリのすべてのイベント（クラッシュ、致命的でないイベント、ANR など）を分析し、問題と呼ばれるイベントのグループを作成します。1 つの問題の中のすべてのイベントには共通の障害点があります。

イベントを問題としてグループ化するために、向上した分析エンジンでは、スタック トレース内のフレーム、例外メッセージ、エラーコード、その他のプラットフォームまたはエラータイプの特性など、イベントの多くの要素を確認するようになりました。

ただし、このようにグループ化されたイベントの中には、障害に至るまでのスタック トレースが異なるものが含まれることがあります。スタック トレースが異なる場合は、根本原因が異なる可能性があります。一つの問題の中のこの違いを表現するため、問題の中にバリアントが作成されるようになりました。個々のバリアントは、一つの問題の中に含まれ、同じ障害点と類似のスタック トレースを持つイベントのサブグループです。バリアントによって、問題の中の最も一般的なスタック トレースをデバッグし、異なる根本原因によって障害が発生しているかどうかを判断できます。

改良点は以下のとおりです。

• [問題] の行に表示されるメタデータを改善
  アプリで問題を簡単に把握し、優先順位を設定できるようになりました。

• 問題の重複の低減
  行番号を変更しても新しい問題は発生しません。

• さまざまな根本原因による複雑な問題のデバッグが容易に
  バリアントを使用して、問題内で最も一般的なスタック トレースをデバッグできます。

• より有意義なアラートとシグナル
  新しい問題は実際の新しいバグを表すようになりました。

• 検索機能の強化
  それぞれの問題に、例外タイプやパッケージ名など、検索可能なメタデータが追加されました。

改良された機能の提供の詳細は次のとおりです。

• アプリから新しいイベントを受け取ると、既存の問題と一致するかどうかが確認されます。

• 一致するものがない場合は、よりスマートなイベント グループ アルゴリズムをイベントに自動的に適用し、改良されたメタデータ設計を使って新しい問題を作成します。

これは、イベントのグループ分けに関する最初の大きなアップデートです。フィードバックがある場合や問題が発生した場合は、レポートに記入してお知らせください。

パンくずリストのログが表示されない

パンくずリストのログ（iOS+ | Android | Flutter | Unity）が表示されない場合は、アプリの Google Analytics の構成を確認することをおすすめします。次の要件を満たしていることを確認してください。

• Firebase プロジェクトで Google Analytics を有効にしています。

• Google Analytics のデータ共有を有効にしている。この設定の詳細については、アナリティクスのデータ共有設定を管理するをご覧ください。

• Google Analytics 用の Firebase SDK（iOS+ | Android | Flutter | Unity）をアプリに追加している。
  Crashlytics SDK に加えて、この SDK も追加する必要があります。

• アプリで使用するすべてのプロダクトで最新バージョンの Firebase SDK（iOS+ | Android | Flutter | Unity）を使用している。

  Apple プラットフォームと Android アプリの場合は、少なくとも次のバージョンの Google Analytics 用 Firebase SDK を使用していることを確認します。 iOS+ - v6.3.1 以降（macOS および tvOS の場合は v8.9.0 以降）| Android - v17.2.3 以降（BoM v24.7.1 以降）。

ベロシティ アラートが表示されない

ベロシティ アラートが表示されない場合は、 を使用していることを確認してください。

クラッシュの影響を受けていない指標が表示されない（または信頼性の低い指標が表示される）

クラッシュの影響を受けていない指標（クラッシュの影響を受けていないユーザーやセッションなど）が表示されない場合や、信頼性の低い指標が表示される場合は、次の点を確認してください。

• を使用している。

• データ収集の設定がクラッシュの影響を受けていない指標の品質に影響していない。

  • 自動クラッシュ レポートを無効にしてオプトイン レポートを有効にした場合、クラッシュ情報は、データ収集を明示的にオプトインしたユーザーからのみ Crashlytics に送信されます。そのため、Crashlytics にはオプトインしたユーザーのクラッシュ情報のみが含まれるため（すべてのユーザーではない）、クラッシュの影響を受けていない指標の精度が影響を受けます。つまり、クラッシュの影響を受けていない指標の信頼性が低下し、アプリの全体的な安定性を反映しなくなる可能性があります。

  • データの自動収集が無効になっている場合は、sendUnsentReports を使用して、デバイス上のキャッシュに保存されたレポートを Crashlytics に送信できます。 この方法を使用すると、Crashlytics にクラッシュ データが送信されますが、セッション データは送信されません。そのため、コンソール グラフには、クラッシュの影響を受けていない指標に低い値またはゼロの値が表示されます。

クラッシュの影響を受けていないユーザーはどのように計算されますか？

クラッシュの影響を受けていない指標についてをご覧ください。

問題に関するノートを表示、書き込み、削除できるのは誰ですか？

ノートを使用すると、特定の問題に関する質問やステータスの更新などについて、プロジェクト メンバーがコメントを残すことができます。

ノートには、投稿したメンバーの Google アカウントのメールアドレスがラベル付けされます。このメールアドレスは、ノートを見ることができるプロジェクト メンバー全員に対して、ノートとともに表示されます。

ノートを表示、書き込み、削除するために必要なアクセス権は次のとおりです。

• 次のいずれかのロールを持つプロジェクト メンバーは、問題に関する既存のノートの表示と削除、新しいノートの書き込みを行うことができます。

  • プロジェクトのオーナーまたは編集者、Firebase 管理者、品質管理者、Crashlytics 管理者

• 次のいずれかのロールを持つプロジェクト メンバーは、問題に関するノートを見ることはできますが、ノートの削除や書き込みはできません。

  • プロジェクトの閲覧者、Firebase 閲覧者、品質閲覧者、Crashlytics 閲覧者

問題の回帰とは

以前にクローズした問題が再発して Crashlytics が新しいレポートを受け取った場合に、対象の問題で回帰が発生したことになります。回帰が発生した問題は、アプリに適した方法で対応できるよう Crashlytics によって自動的に再オープンされます。

次のような場合、Crashlytics は問題を回帰として分類します。

1. Crashlytics が初めて、クラッシュ「A」に関するクラッシュ レポートを受け取りました。Crashlytics は、そのクラッシュに対応する問題（問題「A」）をオープンしました。
2. あなたはこのバグを速やかに修正し、問題「A」をクローズしてから、アプリの新しいバージョンをリリースしました。
3. 問題をクローズした後で、Crashlytics が問題「A」に関する別のレポートを受け取りました。
   • このレポートが、この問題をクローズしたときに Crashlytics で認識されていたバージョン（つまり、なんらかのクラッシュに関するレポートを送信したことがあるバージョン）のアプリから送信されたものである場合は、Crashlytics は問題が回帰であると見なしません。この問題はクローズのままです。
   • このレポートが、この問題をクローズしたときに Crashlytics で認識されていなかったバージョン（つまりクラッシュに関するレポートを以前に送信したことがないバージョン）のアプリから送信されたものである場合、Crashlytics は問題を回帰と見なして再オープンします。

問題の回帰が発生すると、回帰検出アラートが送信されます。つまり回帰シグナルを問題に追加して、Crashlytics が問題を再オープンしたことを知らせます。この回帰アルゴリズムによって問題を再オープンしたくない場合は、問題をクローズする代わりに「ミュート」します。

古いバージョンのアプリで問題の回帰が発生するのはなぜですか？

レポートを送信したアプリのバージョンが、問題をクローズした時点でクラッシュ レポートを一度も送信したことのない古いバージョンである場合、Crashlytics は問題の回帰が発生したと見なし、その問題を再オープンします。

このような状況は、バグを修正し、新しいバージョンのアプリをリリースしたにもかかわらず、バグが修正されていない古いバージョンを利用しているユーザーがいる場合に発生することがあります。問題をクローズした時点でクラッシュ レポートを一度も送信したことのない、古いバージョンのアプリがまだ使用されている場合、そのバージョンでバグが発生してクラッシュ レポートが送信されると、問題の回帰がトリガーされます。

この回帰アルゴリズムによって問題を再オープンしたくない場合は、問題をクローズする代わりに「ミュート」します。

アプリで Google Mobile Ads SDK も使用しているが、クラッシュが取得されない

プロジェクトで Google Mobile Ads SDK と Crashlytics を併用している場合は、例外ハンドラの登録時にクラッシュ レポート機能が干渉している可能性があります。この問題を解決するには、disableSDKCrashReporting を呼び出して Mobile Ads SDK でクラッシュ レポート機能をオフにしてください。

BigQuery データセットはどこに配置されますか？

Crashlytics を BigQuery にリンクすると、作成される新しいデータセットは、Firebase プロジェクトのロケーションに関係なく自動的に米国に配置されます。

dSYM がないか、アップロードされていない

プロジェクトの dSYM をアップロードして詳細な出力を表示するには、以下をご確認ください。

1. プロジェクトのビルドフェーズに Crashlytics 実行スクリプトが含まれていることを確認します。このスクリプトにより、Xcode はビルド時にプロジェクトの dSYM をアップロードできます（スクリプトの追加手順については、Crashlytics の初期化をご覧ください）。プロジェクトを更新したら、強制的にクラッシュさせ、Crashlytics ダッシュボードにクラッシュが表示されることを確認します。

2. Firebase コンソールに「dSYM の不足」に関するアラートが表示される場合は、Xcode でビルドの dSYM が適切に生成されていることを確認します。

3. Xcode が dSYM を適切に生成しているにもかかわらず dSYM が不足している場合は、dSYM のアップロード中に実行スクリプト ツールが停止している可能性があります。この場合は、次の手順をお試しください。

   • Crashlytics の最新バージョンを使用していることをご確認ください。

   • 不足している dSYM ファイルを手動でアップロードします。

     • オプション 1: [dSYMsdSYM] タブの、コンソールベースの [Drag and Drop] オプションを使用して、不足している dSYM ファイルが含まれる zip アーカイブをアップロードします。
     • オプション 2: upload-symbols スクリプトを使用して、不足している dSYM ファイルを dSYMs[dSYM] タブの対象 UUID 用にアップロードします。

4. dSYM の不足やアップロードの失敗が続く場合は、Firebase サポートまでご連絡ください。その際は必ず、ログを含めてください。

クラッシュのシンボリケーションが不十分

スタック トレースのシンボリケーションが不十分と思われる場合は、次の点を確認してください。

• アプリのライブラリのフレームにアプリのコードへの参照がない場合は、-fomit-frame-pointer がコンパイル フラグとして設定されていないことを確認してください。

• アプリのライブラリに (Missing) フレームが複数表示される場合は、Firebase コンソールの Crashlytics の [dSYMs] タブで、（影響を受けるアプリのバージョン用の）オプションの dSYM が不足していると表示されているかどうかを確認します。そのような表示がある場合は、このページの dSYM がないか、アップロードされていないに記載されている dSYM の不足のアラートのトラブルシューティングの手順を実施してください。これらの dSYM をアップロードしても、すでに発生したクラッシュはシンボリケートされませんが、今後のクラッシュはシンボリケートされるようになります。

macOS または tvOS 向けに Crashlytics を使用できますか？

はい。macOS プロジェクトと tvOS プロジェクトに Crashlytics を実装できます。Google Analytics 用 Firebase SDK の v8.9.0 以降を実装して、クラッシュ時に、Google Analytics によって収集された指標（クラッシュの影響を受けていないユーザー、最新リリース、ベロシティ アラート、パンくずリストのログ）にアクセスできるようにしてください。

異なる Apple プラットフォーム上の複数のアプリに対して、1 つの Firebase プロジェクトの Crashlytics を使用できますか？

さまざまな Apple プラットフォーム（iOS、tvOS、Mac Catalyst など）向けに構築されたアプリでも、1 つの Firebase プロジェクトで複数のアプリのクラッシュを報告できるようになりました。以前は、アプリに同じバンドル ID が含まれている場合であっても、アプリを個別の Firebase プロジェクトに分割する必要がありました。

ANR が Android 11 以降でのみ報告されるのはなぜですか？

Crashlytics は、Android 11 以降を搭載したデバイスからの Android アプリの ANR レポートをサポートしています。ANR の収集に使用される基盤となる API（getHistoricalProcessExitReasons）は、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 を表示します。

.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 のラベルが付けられた既存の問題と重複している可能性がある場合に、それを識別して通知することを試みています。

Dexguard でクラッシュが取得されない

以下の例外が表示される場合、Firebase Crashlytics SDK と互換性のないバージョンの DexGuard を使用している可能性があります。

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

この例外によってアプリがクラッシュすることはありませんが、クラッシュ レポートが送信されなくなります。この問題を解決する方法は以下のとおりです。

1. 最新の DexGuard 8.x リリースを使用してください。最新バージョンには、Firebase Crashlytics SDK で必要なルールが含まれています。

2. DexGuard のバージョンを変更したくない場合は、DexGuard 構成ファイルの難読化ルールに次の行を追加してください。

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

Crashlytics ダッシュボードと logcat の NDK スタック トレースの違い

LLVM ツールチェーンと GNU ツールチェーンはアプリのバイナリの読み取り専用セグメントに対するデフォルトの設定と処理方法がそれぞれ異なるため、Firebase コンソールで一貫性のないスタック トレースが生成される可能性があります。この問題を軽減するには、次のリンカーフラグをビルドプロセスに追加します。

• LLVM ツールチェーンの lld リンカーを使用している場合は、次のリンカーフラグを追加します。

  -Wl,--no-rosegment

• GNU ツールチェーンの ld.gold リンカーを使用している場合は、次のリンカーフラグを追加します。

  -Wl,--rosegment

スタック トレースの不整合がまだ発生している場合（またはどちらのフラグもお使いのツールチェーンに関連していない場合）は、代わりに次のリンカーフラグをビルドプロセスに追加してみてください。

-fno-omit-frame-pointer

NDK に独自の Breakpad シンボル ファイル生成ツールのバイナリを使用するにはどうすればよいですか？

Crashlytics プラグインは、カスタマイズされた Breakpad シンボル ファイル生成ツールをバンドルします。Breakpad シンボル ファイルの生成に独自のバイナリを使用する場合は（たとえば、ビルドチェーン内のすべてのネイティブの実行可能ファイルをソースからビルドする場合）、オプションの symbolGeneratorBinary 拡張プロパティを使用して、実行可能ファイルへのパスを指定します。

次の 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
  

Crashlytics は armeabi をサポートしていますか？

Firebase Crashlytics NDK は ARMv5（armeabi）をサポートしていません。この ABI のサポートは NDK r17 で削除されました。

Crashlytics ダッシュボードに、Android アプリのシンボリケートされていないスタック トレースが表示される

Unity の IL2CPP を使用していて、シンボリケートされていないスタック トレースが表示される場合は、次の手順をお試しください。

1. Crashlytics Unity SDK の v8.6.1 以降を使用していることを確認します。

2. シンボル ファイルを生成してアップロードするための、Firebase CLI の crashlytics:symbols:upload コマンドが設定され、実行されていることを確認します。

   リリースビルドを作成するたびに、または Firebase コンソールでシンボリケートされたスタック トレースを表示するビルドを作成するたびに、この CLI コマンドを実行する必要があります。詳しくは、読み取り可能なクラッシュ レポートの取得をご覧ください。

Crashlytics は、IL2CPP を使用するアプリと併用できますか？

はい。Crashlytics は、IL2CPP を使用するアプリに対して、シンボリケートされたスタック トレースを表示できます。この機能は、Android プラットフォームまたは Apple プラットフォームでリリースされたアプリで使用できます。必要な手順は次のとおりです。

1. Crashlytics Unity SDK の v8.6.0 以降を使用していることを確認します。

2. お使いのプラットフォームで必要なタスクを完了します。

   • Apple プラットフォーム アプリの場合: 特別な操作は必要ありません。Apple プラットフォーム アプリの場合、Firebase Unity Editor プラグインが、シンボルをアップロードするように Xcode プロジェクトを自動的に構成します。

   • Android アプリの場合: シンボル ファイルを生成してアップロードするための、Firebase CLI crashlytics:symbols:upload コマンドが設定され、実行されていることを確認します。

     リリースビルドを作成するたびに、または Firebase コンソールでシンボリケートされたスタック トレースを表示するビルドを作成するたびに、この CLI コマンドを実行する必要があります。詳しくは、読み取り可能なクラッシュ レポートの取得をご覧ください。

キャッチされなかった例外をアプリが致命的として報告するのはなぜですか？

キャッチされなかった例外を致命的として報告することで、アプリが引き続き実行されている場合でも、例外が発生すればゲームをプレイできなくなる可能性があることをよりリアルに示すことができます。

致命的エラーの報告を開始すると、クラッシュの影響を受けていないユーザー（CFU）の割合は減少する可能性がありますが、CFU 指標はアプリによるエンドユーザー エクスペリエンスの影響を適切に反映したものになります。

どのような例外が致命的として報告されますか?

キャッチされなかった例外を Crashlytics が致命的な例外として報告するには、次の 2 つの条件が両方とも満たされている必要があります。

• アプリの初期化時に、ReportUncaughtExceptionsAsFatal プロパティを true に設定する必要があります。

• アプリ（または付属のライブラリ）が、キャッチされていない例外をスローしました。作成された後にスローされなかった例外は、キャッチされなかった例外とは見なされません。

キャッチされなかった例外を致命的として報告できるようになった後に、多くの新しい致命的な問題が発生するようになりました。このような例外を適切に処理するにはどうすればよいですか？

キャッチされなかった例外が致命的として報告されるようになった場合、これらのキャッチされなかった例外を処理する方法は、次のとおりです。

• これらのキャッチされなかった例外をキャッチして処理する方法を検討する。
• Unity デバッグ コンソールと Crashlytics に例外をロギングするさまざまな方法を検討する。

スローされた例外をキャッチして処理する

例外は、予期しない状態または例外的な状態を反映するために作成され、スローされます。スローされた例外によって反映される問題を解決するには、プログラムを既知の状態に戻します（このプロセスは例外処理と呼ばれます）。

プログラムを既知の状態に戻せない場合を除き、予測されるすべての例外をキャッチして処理することをおすすめします。

キャッチするコードの種類と、キャッチした例外の処理に使用するコードを制御するには、例外を生成する可能性があるコードを try-catch ブロック内にラップします。特定の例外を適切に処理できるように、catch ステートメントの条件をできるだけ絞り込んでください。

Unity または Crashlytics で例外をログに記録する

Unity または Crashlytics で例外を記録して問題のデバッグに役立てるには、複数の方法があります。

Crashlytics を使用する際の最も一般的な推奨オプションを 2 つ紹介します。

• オプション 1: Unity コンソールに出力するものの、開発中またはトラブルシューティング中は Crashlytics に報告しない

  • 例外の内容を Unity コンソールに出力する Debug.Log(exception)、Debug.LogWarning(exception)、Debug.LogError(exception) を使用して Unity コンソールに出力しますが、例外を再スローしません。

• オプション 2: 次の状況の場合は、Crashlytics にアップロードして、Crashlytics ダッシュボードに統合レポートを表示する:

  • 例外をロギングして、その後発生する可能性のある Crashlytics イベントをデバッグすることが有益である場合は、Crashlytics.Log(exception.ToString()) を使用します。
  • 例外をキャッチして処理した後も、Crashlytics に報告する必要がある場合は、Crashlytics.LogException(exception) を使用して、致命的でないイベントとしてログに記録します。

ただし、致命的なイベントを Unity Cloud Diagnostics に手動で報告する場合は、Debug.LogException を使用できます。このオプションでは、オプション 1 のように Unity コンソールに例外が出力されますが、（すでにスローされているのか、またはキャッチされているのかに関係なく）例外もスローされます。ローカル以外の場所でエラーをスローします。つまり、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
    //
}