このページでは、トラブルシューティングのヘルプと、Crashlytics の使用に関するよくある質問への回答を提供します。探しているものが見つからない場合、または追加のサポートが必要な場合は、 Firebase サポートにお問い合わせください。
一般的なトラブルシューティング/FAQ
クラッシュのないユーザー、ブレッドクラム ログ、ベロシティ アラートが表示されない場合は、Google アナリティクスのアプリの構成を確認することをお勧めします。
Firebase プロジェクトでGoogle アナリティクスが有効になっていることを確認してください。
Firebase コンソールの [統合] > [ Google アナリティクス]ページで、Google アナリティクスのデータ共有が有効になっていることを確認します。データ共有設定は Firebase コンソールに表示されますが、Google アナリティクス コンソールで管理されることに注意してください。
Firebase Crashlytics SDK に加えて、Google アナリティクス用の Firebase SDK をアプリ ( iOS+ | Android ) に追加したことを確認してください。
すべての Firebase SDK ( iOS+ | Android ) で最新バージョンを使用していることを確認してください。
特に、Google アナリティクス用のFirebase SDK の少なくとも次のバージョンを使用していることを確認してください。 Android — v17.2.3+(BoM v24.7.1+) .
Firebase コンソールの [ Issues ] テーブルにリストされている問題には、2 つの異なる形式があることに気付くかもしれません。これが理由です！
Crashlytics は、アプリからのすべてのイベント (クラッシュ、非致命的、ANR) を分析し、同様のイベントを個別の問題にグループ化します。 2023 年 1 月に、アプリのコードに基づいてイベントをグループ化するための改善された分析エンジンと、新しい問題を表示するための更新されたデザインをロールアウトしました。
これらの改善により、次のことが体験できます。
課題行内に表示される改良されたメタデータ
アプリの問題を理解し、トリアージしやすくなりました。重複する問題が少ない
行番号を変更しても、新しい問題は発生しません。より意味のあるアラートとシグナル
新しい問題は、実際には新しいバグを表しています。より強力な検索
各号には、例外の種類やパッケージ名など、より検索可能なメタデータが含まれています。
これらの改善がどのように展開されているかを次に示します。
アプリから新しいイベントを取得すると、それらが既存の問題と一致するかどうかを確認します。
一致するものがない場合は、よりスマートなイベント グループ化アルゴリズムをイベントに自動的に適用し、改良されたメタデータ デザインで新しい課題を作成します。
クラッシュ フリーの値は、アプリを使用したが、特定の期間にクラッシュが発生しなかったユーザーの割合を表します。
クラッシュのないユーザーの割合を計算する式は次のとおりです。その入力値は、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 |
| クラッシュしたユーザー | ハ | B | あ |
水曜日に、クラッシュしていないユーザーの割合は 50% です (2 人中 1 人のユーザーがクラッシュしていませんでした)。
水曜日に 2 人のユーザーがアプリを使用しましたが、そのうち 1 人 (ユーザー B) だけがクラッシュしませんでした。過去 2 日間で、クラッシュが発生していないユーザーの割合は 33.3% です (3 人中 1 人のユーザーがクラッシュを経験していません)。
過去 2 日間で 3 人のユーザーがアプリを使用しましたが、そのうち 1 人 (ユーザー C) だけがクラッシュしませんでした。過去 3 日間で、クラッシュが発生していないユーザーの割合は 0% です (3 人中 0 人のユーザーがクラッシュを経験していません)。
過去 3 日間で 3 人のユーザーがアプリを利用しましたが、そのうち 1 人もクラッシュしませんでした。
メモを使用すると、プロジェクト メンバーは、質問、ステータスの更新など、特定の問題についてコメントできます。
プロジェクト メンバーがメモを投稿すると、Google アカウントのメール アドレスがラベル付けされます。この電子メール アドレスは、メモを表示するアクセス権を持つすべてのプロジェクト メンバーに、メモとともに表示されます。
メモの表示、書き込み、および削除に必要なアクセス権を次に示します。
次のいずれかの役割を持つプロジェクト メンバーは、既存のメモを表示および削除し、課題に新しいメモを書き込むことができます。
- プロジェクトオーナーまたは編集者、 Firebase 管理者、品質管理者、またはCrashlytics 管理者
次のいずれかの役割を持つプロジェクト メンバーは、課題に投稿されたメモを表示できますが、メモを削除または書き込むことはできません。
- Project Viewer 、 Firebase Viewer 、 Quality Viewer 、またはCrashlytics Viewer
統合
プロジェクトで Crashlytics を Google Mobile Ads SDK と一緒に使用している場合、クラッシュ レポーターが例外ハンドラーの登録時に干渉している可能性があります。この問題を解決するには、 disableSDKCrashReportingを呼び出して Mobile Ads SDK のクラッシュ レポートをオフにします。
Crashlytics を BigQuery にリンクすると、作成した新しいデータセットは、Firebase プロジェクトの場所に関係なく、自動的に米国に配置されます。
プラットフォームのサポート
リグレッションの問題
以前に問題をクローズしたときに問題に回帰がありましたが、Crashlytics は問題が再発したという新しいレポートを受け取りました。 Crashlytics は、これらのリグレッションした問題を自動的に再度開き、アプリに応じて対処できるようにします。
Crashlytics が問題をリグレッションとして分類する方法を説明するシナリオの例を次に示します。
- Crashlytics は初めて、Crash "A" に関するクラッシュ レポートを受け取りました。 Crashlytics は、そのクラッシュに対応する問題 (問題 "A") を開きます。
- このバグをすばやく修正し、問題 "A" をクローズしてから、アプリの新しいバージョンをリリースします。
- 問題をクローズした後、Crashlytics は問題「A」に関する別のレポートを受け取ります。
- レポートが、問題をクローズしたときに Crashlytics が認識していたアプリ バージョンからのものである場合 (つまり、そのバージョンがクラッシュのクラッシュ レポートをまったく送信していないことを意味します)、Crashlytics は問題をリグレッションとは見なしません。問題はクローズされたままになります。
- レポートが、問題をクローズしたときに Crashlyticsが認識していなかったアプリ バージョンからのものである場合 (つまり、そのバージョンがクラッシュに関するクラッシュ レポートをまったく送信していないことを意味します)、Crashlytics は問題が後退したと見なし、問題を再度開きます。 .
問題が後退すると、回帰検出アラートを送信し、回帰シグナルを問題に追加して、Crashlytics が問題を再開したことを知らせます。回帰アルゴリズムが原因で問題が再び開かれることを望まない場合は、問題を閉じるのではなく「ミュート」してください。
問題を閉じたときにクラッシュ レポートをまったく送信していなかった古いアプリ バージョンからのレポートである場合、Crashlytics は問題が後退したと見なし、問題を再度開きます。
この状況は、次のような状況で発生する可能性があります: バグを修正し、アプリの新しいバージョンをリリースしましたが、バグを修正していない古いバージョンのユーザーがまだいます。問題をクローズしたときに古いバージョンのいずれかがクラッシュ レポートをまったく送信していなかった場合、それらのユーザーがバグに遭遇し始めた場合、それらのクラッシュ レポートはリグレッションの問題を引き起こします。
回帰アルゴリズムが原因で問題が再び開かれることを望まない場合は、問題を閉じるのではなく「ミュート」してください。