App Center のクラッシュ (Unity)

重要

Visual Studio App Center は、2026 年 6 月 30 日まで引き続きサポートされる分析機能と診断機能を除き、2025 年 3 月 31 日に廃止されました。 詳細を参照してください。

• アンドロイド
• iOS
• MAUI/Xamarin
• UWP
• WPF/WinForms
• React Native
• macOS
• tvOS
• ユニティ

App Center のクラッシュでは、アプリがクラッシュするたびにクラッシュ ログが自動的に生成され、デバイス ストレージにログが記録されます。 ユーザーがアプリを再度起動すると、SDK はクラッシュ レポートを App Center に送信します。 クラッシュの収集は、ベータ版アプリとライブ アプリの両方で機能します。つまり、Google Play に送信されたクラッシュです。 クラッシュ ログには、クラッシュの修正に役立つ貴重な情報が含まれています。

アプリケーションで SDK をまだ設定していない場合は、「 Unity の概要 」セクションの手順に従います。

iOS のクラッシュ ログにはシンボリック化が必要です。 シンボリック化を有効にするには、アプリのシンボルを提供する方法について説明している App Center 診断のドキュメントを参照してください。

重要

Unity 用のクラッシュ SDK では、UWP はサポートされていません。 このページの手順では、Android と iOS についてのみ説明します。

注

デバッガーをアタッチした場合、SDK はクラッシュ ログを転送しません。 アプリをクラッシュさせたときにデバッガーがアタッチされていないことを確認します。

注

Enable CrashReport API で有効場合、SDK はクラッシュ ログを収集しません。

テスト クラッシュを生成する

App Center のクラッシュには、SDK を簡単にテストするためのテスト クラッシュを生成する API が用意されています。 この API は、デバッグ構成とリリース構成をチェックします。 そのため、リリース アプリでは機能しないため、デバッグ時にのみ使用できます。

Crashes.GenerateTestCrash();

注

このメソッドは、 開発ビルド の設定が有効になっている場合にのみ機能します。

以前のクラッシュに関する詳細情報を取得する

App Center のクラッシュには、アプリがクラッシュした場合に備えて詳細情報を提供する 2 つの API があります。

アプリは前のセッションでメモリ不足の警告を受け取りましたか?

SDK を起動した後は、前のセッションでアプリがメモリ警告を受信したかどうかをいつでも確認できます。

bool hadLowMemoryWarning = Crashes.HasReceivedMemoryWarningInLastSessionAsync().Result;

注

このメソッドは、 Awake()では機能しません。

注

メモリが不足しているデバイスでイベントを送信できない場合があります。

前のセッションでアプリがクラッシュしましたか?

SDK を起動した後は、前回の起動時にアプリがクラッシュしたかどうかをいつでも確認できます。

bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();

HasCrashedInLastSessionAsyncの呼び出しは、クラッシュが発生した後にアプリの動作または UI を調整する場合に便利です。 一部の開発者は、お詫びとして追加の UI を表示したり、クラッシュ後に連絡を取ったりします。

前回のクラッシュの詳細

アプリが以前にクラッシュした場合は、最後のクラッシュに関する詳細を取得できます。

ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();

この API の最も一般的なユース ケースは、ユーザーがカスタム のクラッシュ デリゲートまたはリスナーを実装している場合です。

App Center のクラッシュ機能の使い方をカスタマイズする

App Center のクラッシュでは、開発者がクラッシュ ログを App Center に送信する前とタイミングに追加のアクションを実行するためのコールバックが提供されます。

注

App Center が起動 する前に コールバックを設定します。たとえば、Awake メソッドで設定します。App Center は起動直後にクラッシュ処理を開始するためです。

クラッシュを処理する必要がありますか?

特定のクラッシュを処理する必要があるかどうかを判断する場合は、次のコールバックを設定します。 たとえば、システム レベルのクラッシュを無視して、App Center に送信しないことが可能です。

Crashes.ShouldProcessErrorReport = (ErrorReport report) =>
{
     // Check the report in here and return true or false depending on the ErrorReport.
    return true;
};

クラッシュ ログを送信するためのユーザーの同意を求める

ユーザーのプライバシーが重要な場合は、クラッシュ レポートを App Center に送信する前に、ユーザーの確認を取得することをお勧めします。 SDK は、クラッシュ レポートを送信する前にユーザーの確認を待機するように App Center のクラッシュに指示するコールバックを公開します。

コードでこのコールバックを使用する場合は、ユーザーの確認を取得する必要があります。 1 つのオプションは、ダイアログ プロンプトを使用して、[ 常に送信]、[ 送信]、[ 送信しない] のいずれかのオプションを使用することです。 入力に基づいて、App Center Crashes に指示を与えることで、そのクラッシュが適切に処理されます。

注

SDK にはこれに対するダイアログは表示されません。アプリは、ユーザーの同意を求めるために独自の UI を提供する必要があります。

次のコールバックは、クラッシュを送信する前にユーザーの確認を待機するように SDK に指示する方法を示しています。

Crashes.ShouldAwaitUserConfirmation = () =>
{
    // Build your own UI to ask for user consent here. SDK doesn't provide one by default.

    // Return true if you built a UI for user consent and are waiting for user input on that custom UI, otherwise false.
    return true;
};

コールバックが trueを返す場合は、ユーザーのアクセス許可を取得し、次の API を使用して結果を SDK にメッセージする必要があります。

// Depending on the user's choice, call Crashes.NotifyUserConfirmation() with the right value.
Crashes.NotifyUserConfirmation(UserConfirmation.DontSend);
Crashes.NotifyUserConfirmation(UserConfirmation.Send);
Crashes.NotifyUserConfirmation(UserConfirmation.AlwaysSend);

例として、 カスタム ダイアログの例を参照できます。

クラッシュ ログの送信状態に関する情報を取得する

場合によっては、アプリのクラッシュの状態を知りたい場合があります。 一般的なユース ケースは、アプリがクラッシュ レポートを送信していることをユーザーに通知する UI を表示することです。 もう 1 つのシナリオは、再起動後すぐにクラッシュ ログを送信できるようにアプリの動作を調整する場合です。 App Center のクラッシュには、何が行われたかを通知するために行うことができる 3 つの異なるコールバックが用意されています。

SDK がクラッシュ ログを送信する前に、次のコールバックが呼び出されます

Crashes.SendingErrorReport += (errorReport) =>
{
    // Your code, e.g. to present a custom UI.
};

エンドポイントでネットワークの問題や停止が発生し、アプリを再起動すると、プロセスの再起動後に SendingErrorReport が再度トリガーされます。

SDK がクラッシュ ログを正常に送信した後、次のコールバックが呼び出されます

Crashes.SentErrorReport += (errorReport) =>
{
    // Your code, e.g. to hide the custom UI.
};

SDK がクラッシュ ログを送信できなかった場合は、次のコールバックが呼び出されます

Crashes.FailedToSendErrorReport += (errorReport, exception) =>
{
    // Your code goes here.
};

FailedToSendErrorReportを受け取るということは、4xx コードが発生したなどの回復不可能なエラーを意味します。 たとえば、 401 は、 appSecret が間違っていることを意味します。

このコールバックは、ネットワークの問題である場合はトリガーされません。 この場合、SDK は再試行を続けます (また、ネットワーク接続がダウンしている間も再試行を一時停止します)。

クラッシュまたはハンドルされない例外レポートに添付ファイルを追加する

必要に応じて、クラッシュまたは ハンドルされない例外 レポートにバイナリ添付ファイルとテキスト添付ファイルを追加することもできます。 APP Center ポータルで表示できるように、SDK によってレポートと共に送信されます。 格納されたレポートを送信する直前に、次のコールバックが呼び出されます。 クラッシュの場合は、次のアプリケーションの起動時に発生します。 ハンドルされない例外の場合、添付ファイルを送信するには オプトイン する必要があります。 その名前はミニダンプ ファイル用に予約されているため、添付ファイルの名前が minidump.dmpを確認してください。 テキストと画像をレポートに添付する方法の例を次に示します。

Crashes.GetErrorAttachments = (ErrorReport report) =>
{
    // Your code goes here.
    return new ErrorAttachmentLog[]
    {
        ErrorAttachmentLog.AttachmentWithText("Hello world!", "hello.txt"),
        ErrorAttachmentLog.AttachmentWithBinary(Encoding.UTF8.GetBytes("Fake image"), "fake_image.jpeg", "image/jpeg")
    };
};

クラッシュは、 IsCrash プロパティを持つレポートのハンドルされない例外とは区別されます。 クラッシュの場合はプロパティが true になり、それ以外の場合は false になります。

注

サイズ制限は、現在 7 MB の添付ファイルに対するものです。 大きな添付ファイルを送信しようとすると、エラーが発生します。

注

GetErrorAttachments はメインスレッドで呼び出され、作業がフレーム単位で分割されません。 ゲーム ループをブロックしないようにするには、このコールバックで実行時間の長いタスクを実行しないでください。

実行時に App Center のクラッシュを有効または無効にする

実行時に App Center のクラッシュを有効または無効にすることができます。 無効にした場合、SDK はアプリのクラッシュ レポートを実行しません。

Crashes.SetEnabledAsync(false);

App Center のクラッシュを再度有効にするには、同じ API を使用しますが、パラメーターとして true を渡します。

Crashes.SetEnabledAsync(true);

他の API 呼び出し ( IsEnabledAsync など) の整合性を保つには、この呼び出しを待つ必要はありません。

状態は、アプリケーションの起動間でデバイスのストレージに保持されます。

App Center のクラッシュ機能が有効になっているかどうかを確認する

App Center のクラッシュが有効になっているかどうかを確認することもできます。

bool isEnabled = await Crashes.IsEnabledAsync();

Unity で処理された例外

App Center では、Unity で処理された例外を使用してエラーを追跡することもできます。 これを行うには、 TrackError メソッドを使用します。

try {
    // your code goes here.
} catch (Exception exception) {
    Crashes.TrackError(exception);
}

エラーに関する詳細なコンテキストについては、プロパティを添付することもできます。 プロパティを文字列のディクショナリとして渡します。 このステップはオプションです。

try {
    // your code goes here.
} catch (Exception exception) {
    var properties = new Dictionary<string, string>
    {
        { "Category", "Music" },
        { "Wifi", "On" }
    };
    Crashes.TrackError(exception, properties);
}

必要に応じて、処理されたエラー レポートにバイナリ添付ファイルとテキスト添付ファイルを追加することもできます。 次の例に示すように、添付ファイル ErrorAttachmentLog オブジェクトの配列として渡します。

try {
    // your code goes here.
} catch (Exception exception) {
    var attachments = new ErrorAttachmentLog[]
    {
        ErrorAttachmentLog.AttachmentWithText("Hello world!", "hello.txt"),
        ErrorAttachmentLog.AttachmentWithBinary(Encoding.UTF8.GetBytes("Fake image"), "fake_image.jpeg", "image/jpeg")
    };
    Crashes.TrackError(exception, attachments: attachments);
}

Unity での未処理例外

ハンドルされない例外を報告する

初期設定では、App Center SDK は、致命的なクラッシュを引き起こさないアプリ内のハンドルされない例外を報告しません。 この機能を有効にするには、次のメソッドを呼び出します。

Crashes.ReportUnhandledExceptions(true);

この API を呼び出した後、App Center では、前述の処理された例外と同様に、App Center ポータルで未処理のすべての例外が問題としてログに記録されます。 この機能を無効にするには、パラメーターと同じ API パッシング false を呼び出します。

Crashes.ReportUnhandledExceptions(false);

注

App Center SDK によって検出された一部のハンドルされない例外は、App Center UI にエラーとして表示されます。 これは、Unity が既定でハンドルされない例外をキャッチするためです。つまり、アプリは終了せず、クラッシュとは見なされません。

ハンドルされない例外レポートに添付ファイルを追加する

既定では、App Center SDK では、ハンドルされない例外に対して添付ファイルは有効になりません。 この機能を有効にするには、enableAttachmentsCallback メソッドのReportUnhandledExceptionsブール値パラメーターをtrueに設定します。

Crashes.ReportUnhandledExceptions(true, true);

必要に応じて 、GetErrorAttachments コールバックを実装することで、ハンドルされない例外レポートに添付ファイルを追加できます。

NDK クラッシュの報告

クラッシュの報告

App Center で適切なクラッシュ レポートを受け取るために、まず、上記の手順に従って App Center Crashs SDK が設定されていることを確認します。

ブレークパッド ライブラリのビルド

次に、公式な Google Breakpad for Android README に記載された手順に従って、Google Breakpad を含めてコンパイルする必要があります。 Unity で使用するには、アプリにバイナリを含めます。

注

App Center SDK では、既定では Google Breakpad はバンドルされません。

例外ハンドラーを取り付ける

Google Breakpad を追加したら、NDK クラッシュ ハンドラーをアタッチします。

/* Attach NDK Crash Handler. */
var minidumpDir = Crashes.GetMinidumpDirectoryAsync();
setupNativeCrashesListener(minidumpDir.Result);

...

[DllImport("YourLib")]
private static extern void setupNativeCrashesListener(string path);

setupNativeCrashesListenerメソッドは、C/C++ で実装する必要があるネイティブ メソッドです。

#include <android/log.h>
#include "google-breakpad/src/client/linux/handler/exception_handler.h"
#include "google-breakpad/src/client/linux/handler/minidump_descriptor.h"

static google_breakpad::ExceptionHandler exception_handler(google_breakpad::MinidumpDescriptor(), NULL, dumpCallback, NULL, true, -1);

/**
 * Registers breakpad as the exception handler for NDK code.
 * @param path minidump directory path returned from Crashes.GetMinidumpDirectoryAsync()
 */
extern "C" void setupNativeCrashesListener(const char *path) {
    google_breakpad::MinidumpDescriptor descriptor(path);
    exception_handler.set_minidump_descriptor(descriptor);
}

トラブルシューティングに dumpCallback が使用される場所:

/*
 * Triggered automatically after an attempt to write a minidump file to the breakpad folder.
 */
static bool dumpCallback(const google_breakpad::MinidumpDescriptor &descriptor,
                         void *context,
                         bool succeeded) {

    /* Allow system to log the native stack trace. */
    __android_log_print(ANDROID_LOG_INFO, "YourLogTag",
                        "Wrote breakpad minidump at %s succeeded=%d\n", descriptor.path(),
                        succeeded);
    return false;
}

これらのメソッドが適切に設定されると、アプリは再起動時にミニダンプを App Center に自動的に送信します。 トラブルシューティングを行うには、詳細ログを使用して、アプリの再起動後にミニダンプが送信されるかどうかを確認できます。

注

App Center では、ミニダンプの添付ファイルに予約名 minidump.dmp が使用されます。 添付ファイルがミニダンプ ファイルでない限り、添付ファイルに別の名前を付けて、適切に処理できるようにします。

警告

x86 エミュレーターでクラッシュをキャプチャできなくなる、ブレークパッドには既知のバグがあります。

シンボリック化

クラッシュの処理の詳細については、 診断 ドキュメントを参照してください。