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

クラッシュの影響を受けていないユーザー、パンくずリストのログ、ベロシティ アラートが表示されない

クラッシュの影響を受けていないユーザー、パンくずリストのログ、ベロシティ アラートが表示されない場合は、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 など）を分析し、問題と呼ばれるイベントのグループを作成します。一つの問題の中のすべてのイベントには共通の障害点があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

クラッシュなしの値は、特定の期間にアプリを利用したユーザーのうち、クラッシュが発生しなかったユーザーの割合を表します。

クラッシュの影響を受けていないユーザーの割合を計算する式は次のとおりです。入力値は Google アナリティクスから提供されます。

CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100

• クラッシュが発生すると、Google アナリティクスは app_exception イベントタイプを送信します。CRASHED_USERS はそのイベントタイプに関連付けられているユーザーの数を表します。

• ALL_USERS は、Crashlytics ダッシュボードの右上にあるプルダウン メニューから選択した期間中にアプリを利用したユーザーの合計数を表します。

クラッシュの影響を受けていないユーザーの割合は、時間の経過に伴う集計です。平均ではありません。

たとえば、アプリに 3 人のユーザーがいて、それぞれユーザー A、ユーザー B、ユーザー C とします。次の表は、それぞれの日にアプリを利用したユーザーと、その日にクラッシュが発生したユーザーを示しています。

• 水曜日にクラッシュの影響を受けていないユーザーの割合は 50% です（ユーザーの 2 人に 1 人はクラッシュの影響を受けませんでした）。
  水曜日にアプリを利用したユーザーは 2 人でしたが、そのうち 1 人（ユーザー B）にはクラッシュが発生しませんでした。

• 過去 2 日間にクラッシュの影響を受けていないユーザーの割合は 33.3% です（ユーザーの 3 人に 1 人はクラッシュの影響を受けませんでした）。
  過去 2 日間にアプリを利用したユーザーは 3 人でしたが、クラッシュが発生しなかったのはそのうち 1 人（ユーザー C）だけでした。

• 過去 3 日間にクラッシュの影響を受けていないユーザーの割合は 0% です（ユーザー 3 人の中にクラッシュの影響を受けなかったユーザーはいませんでした）。
  過去 3 日間にアプリを利用したユーザーは 3 人でしたが、クラッシュが発生しなかったユーザーはいませんでした。

クラッシュの影響を受けていないユーザーの値を異なる期間で比較しないでください。1 人のユーザーがクラッシュを経験する確率は、アプリの使用回数が増えるほど高くなるため、クラッシュの影響を受けていないユーザーの値は、期間が長くなるほど小さくなる可能性があります。

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

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

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

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

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

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

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

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

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

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

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

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

問題の回帰とは

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

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

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

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

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

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

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

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