iOS+
Android
Flutter
Unity
このページでは、Crashlytics の使用に関するトラブルシューティングのヘルプ情報と、よくある質問への回答を紹介します。お探しの情報が見つからない場合や、サポートが必要な場合は、Firebase サポート にお問い合わせください。
一般的なトラブルシューティングとよくある質問
クラッシュの影響を受けていない指標またはベロシティ アラートが表示されない
クラッシュの影響を受けていない指標（クラッシュの影響を受けていないユーザーやセッションなど）またはベロシティ アラートが表示されない場合は、
Crashlytics SDK v10.8.0 以降
を使用していることを確認してください。
パンくずリストのログが表示されない
パンくずリストのログ が表示されない場合は、アプリの Google Analytics の構成を確認することをおすすめします。次の要件を満たしていることを確認してください。
dSYM がないか、アップロードされていない
プロジェクトの dSYM をアップロードして詳細な出力を表示するには、以下をご確認ください。
プロジェクトのビルドフェーズに Crashlytics 実行スクリプトが含まれていることを確認します。このスクリプトにより、Xcode はビルド時にプロジェクトの dSYM をアップロードできます（スクリプトの追加手順については、Crashlytics の初期化強制的にクラッシュ させ、Crashlytics ダッシュボードにクラッシュが表示されることを確認します。
Firebase コンソールに「dSYM の不足」に関するアラートが表示される場合は、Xcode でビルドの dSYM が適切に生成されている ことを確認します。
Xcode が dSYM を適切に生成しているにもかかわらず dSYM が不足している場合は、dSYM のアップロード中に実行スクリプト ツールが停止している可能性があります。この場合は、次の手順をお試しください。
dSYM の不足やアップロードの失敗が続く場合は、Firebase サポート までご連絡ください。その際は必ず、ログを含めてください。
クラッシュのシンボリケーションが不十分
スタック トレースのシンボリケーションが不十分と思われる場合は、次の点を確認してください。
アプリのライブラリのフレームにアプリのコードへの参照がない場合は、-fomit-frame-pointer
アプリのライブラリに (Missing) フレームが複数表示される場合は、Firebase コンソールの Crashlytics の [dSYMs ] タブdSYM がないか、アップロードされていない に記載されている dSYM の不足のアラートのトラブルシューティングの手順を実施してください。これらの dSYM をアップロードすると、
問題に関するノートを表示、書き込み、削除できるのは誰ですか？
ノートを使用すると、特定の問題に関する質問やステータスの更新などについて、プロジェクト メンバーがコメントを残すことができます。
ノートには、投稿したメンバーの Google アカウントのメールアドレスがラベル付けされます。このメールアドレスは、ノートを見ることができるプロジェクト メンバー全員に対して、ノートとともに表示されます。
ノートを表示、書き込み、削除するために必要なアクセス権は次のとおりです。
問題に関するノートを表示、書き込み、削除できるのは誰ですか？
ノートを使用すると、特定の問題に関する質問やステータスの更新などについて、プロジェクト メンバーがコメントを残すことができます。
ノートには、投稿したメンバーの Google アカウントのメールアドレスがラベル付けされます。このメールアドレスは、ノートを見ることができるプロジェクト メンバー全員に対して、ノートとともに表示されます。
ノートを表示、書き込み、削除するために必要なアクセス権は次のとおりです。
統合
アプリで Google Mobile Ads SDK も使用しているが、クラッシュが取得されない
プロジェクトで Google Mobile Ads SDK と Crashlytics を併用している場合は、例外ハンドラの登録時にクラッシュ レポート機能が干渉している可能性があります。この問題を解決するには、disableSDKCrashReporting を呼び出して Mobile Ads SDK でクラッシュ レポート機能をオフにしてください。
BigQuery データセットはどこに配置されますか？
Crashlytics を BigQuery にリンクすると、作成される新しいデータセットは、Firebase プロジェクトのロケーションに関係なく自動的に米国に配置されます。
問題の回帰
問題の回帰とは
以前にクローズした問題が再発して Crashlytics が新しいレポートを受け取った場合に、対象の問題で回帰が発生したことになります。回帰が発生した問題は、アプリに適した方法で対応できるよう Crashlytics によって自動的に再オープンされます。
次のような場合、Crashlytics は問題を回帰として分類します。
Crashlytics が初めて、クラッシュ「A」に関するクラッシュ レポートを受け取りました。Crashlytics は、そのクラッシュに対応する問題（問題「A」）をオープンしました。あなたはこのバグを速やかに修正し、問題「A」をクローズしてから、アプリの新しいバージョンをリリースしました。
問題をクローズした後で、Crashlytics が問題「A」に関する別のレポートを受け取りました。このレポートが、この問題をクローズしたときに Crashlytics Crashlytics は問題が回帰であると見なしません。この問題はクローズのままです。
このレポートが、この問題をクローズしたときに Crashlytics で認識されていなかった バージョン（つまりクラッシュに関するレポートを以前に送信したことがないバージョン）のアプリから送信されたものである場合、Crashlytics は問題を回帰と見なして再オープンします。
注: 2022 年 2 月よりも前には、問題をクローズしたときに認識されていたアプリのバージョンである場合も含めて、Crashlytics は任意のアプリ バージョンで再発した問題を回帰として分類していました。Crashlytics で回帰を正確に識別できないことがありました。そこで現在は、上記の規則が使用されています。 問題の回帰が発生すると、回帰検出アラートが送信されます。つまり回帰シグナルを問題に追加して、Crashlytics が問題を再オープンしたことを知らせます。この回帰アルゴリズムによって問題を再オープンしたくない場合は、問題をクローズする代わりに「ミュート」します。
古いバージョンのアプリで問題の回帰が発生するのはなぜですか？
レポートを送信したアプリのバージョンが、問題をクローズした時点でクラッシュ レポートを一度も送信したことのない古いバージョンである場合、Crashlytics は問題の回帰が発生したと見なし、その問題を再オープンします。
このような状況は、バグを修正し、新しいバージョンのアプリをリリースしたにもかかわらず、バグが修正されていない古いバージョンを利用しているユーザーがいる場合に発生することがあります。問題をクローズした時点でクラッシュ レポートを一度も送信したことのない、古いバージョンのアプリがまだ使用されている場合、そのバージョンで
この回帰アルゴリズムによって問題を再オープンしたくない場合は、問題をクローズする代わりに「ミュート」します。
注: 2022 年 2 月よりも前には、問題をクローズしたときに認識されていたアプリのバージョンである場合も含めて、Crashlytics は任意のアプリ バージョンで再発した問題を回帰として分類していました。その結果、Crashlytics で回帰を正確に識別できないことがありました。そこで現在は、上記の規則が使用されています。
