このページでは、トラブルシューティングのヘルプと、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+) .
Crashlytics は、Android 11 以降を実行するデバイスからの Android アプリの ANR レポートをサポートしています。 ANR ( getHistoricalProcessExitReasons ) を収集するために使用する基になる API は、SIGQUIT またはウォッチドッグ ベースのアプローチよりも信頼性が高くなります。この API は、Android 11 以降のデバイスでのみ使用できます。
Google Play と Crashlytics の間で ANR の数が一致しない場合があります。これは、ANR データの収集と報告のメカニズムの違いによるものです。 Crashlytics はアプリの次回起動時に ANR を報告しますが、Android Vitals は ANR の発生後に ANR データを送信します。
さらに、Crashlytics は、Android 11 以降を実行しているデバイスで発生した ANR のみを表示しますが、Google Play サービスとデータ収集の同意が受け入れられたデバイスからの ANR を表示する Google Play とは異なります。
LLVM と GNU ツールチェーンには、アプリのバイナリの読み取り専用セグメントに対する個別のデフォルトと処理があり、Firebase コンソールで一貫性のないスタック トレースが生成される場合があります。これを軽減するには、次のリンカー フラグをビルド プロセスに追加します。
LLVM ツールチェーンの
lldリンカーを使用している場合は、以下を追加します。-Wl,--no-rosegmentGNU ツールチェーンの
ld.goldリンカーを使用している場合は、次を追加します。-Wl,--rosegment
スタック トレースの不整合が引き続き発生する場合 (または、どちらのフラグもツールチェーンに関係しない場合) は、代わりにビルド プロセスに次を追加してみてください。
-fno-omit-frame-pointer
Crashlytics プラグインには、カスタマイズされた Breakpad シンボル ファイル ジェネレーターがバンドルされています。独自のバイナリを使用して Breakpad シンボル ファイルを生成する場合 (たとえば、ビルド チェーン内のすべてのネイティブ実行可能ファイルをソースからビルドする場合)、オプションのsymbolGeneratorBinary拡張プロパティを使用して、実行可能ファイルへのパスを指定します。
次の 2 つの方法のいずれかで、Breakpad シンボル ファイル ジェネレーター バイナリへのパスを指定できます。
オプション 1 :
build.gradleファイルでfirebaseCrashlytics拡張機能を介してパスを指定します。アプリ レベルの
build.gradleファイルに次を追加します。android { // ... buildTypes { // ... release { // ... firebaseCrashlytics { // existing; required for either symbol file generator nativeSymbolUploadEnabled true // Add this optional new block to specify the path to the executable symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }オプション 2 : Gradle プロパティ ファイルのプロパティ ラインでパスを指定する
com.google.firebase.crashlytics.symbolGeneratorBinaryプロパティを使用して、実行可能ファイルへのパスを指定できます。Gradle プロパティ ファイルを手動で更新するか、コマンド ラインからファイルを更新できます。たとえば、コマンド ラインでパスを指定するには、次のようなコマンドを使用します。
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
次の例外が表示される場合は、Firebase Crashlytics SDK と互換性のないバージョンの DexGuard を使用している可能性があります。
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
この例外によってアプリがクラッシュすることはありませんが、クラッシュ レポートを送信できなくなります。これを修正するには:
最新の DexGuard 8.x リリースを使用していることを確認してください。最新バージョンには、Firebase Crashlytics SDK で必要なルールが含まれています。
DexGuard のバージョンを変更したくない場合は、難読化ルール (DexGuard 構成ファイル内) に次の行を追加してみてください。
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
アプリがファイル拡張子を公開しない難読化ツールを使用している場合、Crashlytics は既定で.javaファイル拡張子を持つ各問題を生成します。
Crashlytics が正しいファイル拡張子で問題を生成できるように、アプリが次の設定を使用していることを確認してください。
- Android Gradle 4.2.0 以降を使用
- 難読化をオンにして R8 を使用します。アプリを R8 に更新するには、このドキュメントに従ってください。
上記の設定に更新した後、既存の.javaの問題と重複する新しい.ktの問題が発生する可能性があることに注意してください。その状況の詳細については、 FAQを参照してください。
2021 年 12 月中旬以降、Crashlytics は Kotlin を使用するアプリケーションのサポートを改善しました。
最近まで、利用可能な難読化ツールはファイル拡張子を公開していなかったため、Crashlytics はデフォルトで.javaファイル拡張子を使用して各問題を生成していました。ただし、Android Gradle 4.2.0 の時点で、R8 はファイル拡張子をサポートしています。
今回の更新により、Crashlytics は、アプリ内で使用される各クラスが Kotlin で記述されているかどうかを判断し、問題の署名に正しいファイル名を含めることができるようになりました。アプリが次のように設定されている場合、クラッシュは (必要に応じて) .ktファイルに正しく起因するようになりました。
- あなたのアプリは Android Gradle 4.2.0 以降を使用しています。
- あなたのアプリは、難読化をオンにして R8 を使用しています。
新しいクラッシュには問題の署名に正しいファイル拡張子が含まれるようになったため、実際には既存の.javaラベルの問題の複製である新しい.kt問題が表示される場合があります。 Firebase コンソールでは、新しい.ktの問題が既存の.javaラベルの問題と重複している可能性があるかどうかを特定して、あなたに連絡しようとします。
クラッシュ フリーの値は、アプリを使用したが、特定の期間にクラッシュが発生しなかったユーザーの割合を表します。
クラッシュのないユーザーの割合を計算する式は次のとおりです。その入力値は、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 プロジェクトの場所に関係なく、自動的に米国に配置されます。
プラットフォームのサポート
Firebase Crashlytics NDK は ARMv5 (armeabi) をサポートしていません。この ABI のサポートは、NDK r17 で削除されました。
リグレッションの問題
以前に問題をクローズしたときに問題に回帰がありましたが、Crashlytics は問題が再発したという新しいレポートを受け取りました。 Crashlytics は、これらのリグレッションした問題を自動的に再度開き、アプリに応じて対処できるようにします。
Crashlytics が問題をリグレッションとして分類する方法を説明するシナリオの例を次に示します。
- Crashlytics は初めて、Crash "A" に関するクラッシュ レポートを受け取りました。 Crashlytics は、そのクラッシュに対応する問題 (問題 "A") を開きます。
- このバグをすばやく修正し、問題 "A" をクローズしてから、アプリの新しいバージョンをリリースします。
- 問題をクローズした後、Crashlytics は問題「A」に関する別のレポートを受け取ります。
- レポートが、問題をクローズしたときに Crashlytics が認識していたアプリ バージョンからのものである場合 (つまり、そのバージョンがクラッシュのクラッシュ レポートをまったく送信していないことを意味します)、Crashlytics は問題をリグレッションとは見なしません。問題はクローズされたままになります。
- レポートが、問題をクローズしたときに Crashlyticsが認識していなかったアプリ バージョンからのものである場合 (つまり、そのバージョンがクラッシュに関するクラッシュ レポートをまったく送信していないことを意味します)、Crashlytics は問題が後退したと見なし、問題を再度開きます。 .
問題が後退すると、回帰検出アラートを送信し、回帰シグナルを問題に追加して、Crashlytics が問題を再開したことを知らせます。回帰アルゴリズムが原因で問題が再び開かれることを望まない場合は、問題を閉じるのではなく「ミュート」してください。
問題を閉じたときにクラッシュ レポートをまったく送信していなかった古いアプリ バージョンからのレポートである場合、Crashlytics は問題が後退したと見なし、問題を再度開きます。
この状況は、次のような状況で発生する可能性があります: バグを修正し、アプリの新しいバージョンをリリースしましたが、バグを修正していない古いバージョンのユーザーがまだいます。問題をクローズしたときに古いバージョンのいずれかがクラッシュ レポートをまったく送信していなかった場合、それらのユーザーがバグに遭遇し始めた場合、それらのクラッシュ レポートはリグレッションの問題を引き起こします。
回帰アルゴリズムが原因で問題が再び開かれることを望まない場合は、問題を閉じるのではなく「ミュート」してください。