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


このページでは、Crashlytics の使用に関するトラブルシューティングのヘルプ情報と、よくある質問への回答を紹介します。お探しの情報が見つからない場合や、サポートが必要な場合は、Firebase サポートにお問い合わせください。

一般的なトラブルシューティングとよくある質問

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クラッシュの影響を受けていない指標(クラッシュの影響を受けていないユーザーやセッションなど)またはベロシティ アラートが表示されない場合は、 Crashlytics SDK v10.8.0 以降 を使用していることを確認してください。

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

プロジェクトの 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 をアップロードすると、すでに発生したクラッシュはシンボリケートされませんが、今後のクラッシュはシンボリケートされるようになります。

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

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

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

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

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

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

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

統合

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

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

プラットフォーム サポート

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

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

問題の回帰

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

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

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

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

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

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

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