このページでは、Crashlyticsの使用に関してよくある質問に対するトラブルシューティングのヘルプと回答を提供します。探しているものが見つからない場合、または追加のヘルプが必要な場合は、 Firebaseサポートにお問い合わせください。
一般的なトラブルシューティング/FAQ
クラッシュのないユーザー、ブレッドクラムログ、速度アラートが表示されない場合は、Googleアナリティクスのアプリの構成を確認することをお勧めします。
FirebaseプロジェクトでGoogleアナリティクスが有効になっていることを確認してください。
Firebaseコンソールの[統合]>[GoogleAnalytics]ページで、GoogleAnalyticsのデータ共有が有効になっていることを確認します。データ共有設定はFirebaseコンソールに表示されますが、Googleアナリティクスコンソールで管理されることに注意してください。
Firebase Crashlytics SDKに加えて、Firebase SDK for Google Analyticsがアプリに追加されていることを確認してください（ iOS + | Android ）。
すべてのFirebaseSDK（ iOS + | Android ）に最新バージョンを使用していることを確認してください。
特に、Firebase SDK for GoogleAnalyticsの少なくとも次のバージョンを使用していることを確認してください。iOS+ — v6.3.1 +（macOSおよびtvOSの場合はv8.9.0 +）| Android — v17.2.3 +（BoM v24.7.1+） 。
クラッシュフリーの値は、アプリを使用したものの、特定の期間にクラッシュが発生しなかったユーザーの割合を表します。
クラッシュのないユーザーの割合を計算する式は次のとおりです。その入力値はGoogleAnalyticsによって提供されます。
1 - ( CRASHED_USERS / ALL_USERS )
クラッシュが発生すると、Google Analyticsは
app_exceptionイベントタイプを送信し、 CRASHED_USERSはそのイベントタイプに関連付けられているユーザーの数を表します。ALL_USERSは、Crashlyticsダッシュボードの右上にあるドロップダウンメニューから選択した期間にアプリを使用したユーザーの総数を表します。
アナリティクスダッシュボードで、アプリのapp_exceptionイベントの数を確認できます。クラッシュの処理方法にわずかな違いがあるため、Analyticsダッシュボードに表示されるapp_exception番号は、クラッシュのないユーザーの計算で使用される番号と異なる場合があることに注意してください。
クラッシュのないユーザーの割合は、平均ではなく、時間の経過に伴う集計です。
たとえば、アプリに3人のユーザーがいるとします。これらをユーザーA、ユーザーB、ユーザーCと呼びます。次の表は、毎日アプリを使用しているユーザーと、その日にクラッシュしたユーザーを示しています。
| 月曜日 | 火曜日 | 水曜日 | |
|---|---|---|---|
| アプリを利用したユーザー | A、B、C | A、B、C | A、B |
| クラッシュしたユーザー | C | B | A |
水曜日のクラッシュフリーユーザーの割合は50％です（2人に1人のユーザーがクラッシュフリーでした）。
水曜日に2人のユーザーがアプリを使用しましたが、クラッシュが発生しなかったのは1人（ユーザーB）のみでした。過去2日間で、クラッシュのないユーザーの割合は33.3％です（3人に1人のユーザーがクラッシュしませんでした）。
過去2日間に3人のユーザーがアプリを使用しましたが、クラッシュが発生しなかったのは1人（ユーザーC）のみでした。過去3日間、クラッシュのないユーザーの割合は0％です（3人のユーザーのうち0人がクラッシュのない状態でした）。
過去3日間に3人のユーザーがアプリを使用しましたが、クラッシュは発生していません。
統合
プロジェクトでCrashlyticsをGoogleMobileAds SDKと一緒に使用している場合、例外ハンドラーの登録時にクラッシュレポーターが干渉している可能性があります。この問題を修正するには、disableSDKCrashReportingを呼び出して、 disableSDKCrashReportingのクラッシュレポートをオフにします。
CrashlyticsをBigQueryにリンクすると、Firebaseプロジェクトの場所に関係なく、作成した新しいデータセットが自動的に米国に配置されます。
プラットフォームのサポート
退行した問題
以前に問題をクローズしたときに問題にリグレッションが発生しましたが、Crashlyticsは問題が再発したという新しいレポートを取得します。 Crashlyticsは、これらのリグレッションされた問題を自動的に再度開き、アプリに応じて適切に対処できるようにします。
Crashlyticsが問題をリグレッションとして分類する方法を説明するシナリオの例を次に示します。
- 初めて、Crashlyticsはクラッシュ「A」に関するクラッシュレポートを取得します。 Crashlyticsは、そのクラッシュに対応する問題を開きます（問題「A」）。
- このバグをすばやく修正し、問題「A」を閉じてから、アプリの新しいバージョンをリリースします。
- 問題をクローズした後、Crashlyticsは問題「A」に関する別のレポートを取得します。
- レポートが、問題を閉じたときにCrashlyticsが知っていたアプリバージョンからのものである場合（つまり、バージョンがクラッシュのクラッシュレポートを送信した場合）、Crashlyticsは問題がリグレッションされたとは見なしません。問題は解決されたままになります。
- レポートが、問題を閉じたときにCrashlyticsが認識していなかったアプリバージョンからのものである場合（つまり、バージョンがクラッシュのクラッシュレポートをまったく送信していなかった場合）、Crashlyticsは問題がリグレッションを起こしていると見なし、問題を再度開きます。 。
問題がリグレッションを起こすと、リグレッション検出アラートを送信し、リグレッションシグナルを問題に追加して、Crashlyticsが問題を再開したことを通知します。回帰アルゴリズムのために問題を再開したくない場合は、問題を閉じるのではなく「ミュート」します。
レポートが、問題を閉じたときにクラッシュレポートをまったく送信していなかった古いアプリバージョンからのものである場合、Crashlyticsは問題がリグレッションを起こしていると見なし、問題を再度開きます。
この状況は、次の状況で発生する可能性があります。バグを修正してアプリの新しいバージョンをリリースしたが、バグ修正が行われていない古いバージョンのユーザーがまだいる。偶然にも、問題を閉じたときにこれらの古いバージョンの1つがクラッシュレポートをまったく送信せず、それらのユーザーがバグに遭遇し始めた場合、それらのクラッシュレポートはリグレッションされた問題をトリガーします。
回帰アルゴリズムのために問題を再開したくない場合は、問題を閉じるのではなく「ミュート」します。