Selhání App Center (Unity)
Důležité
Visual Studio App Center je naplánované k vyřazení na 31. března 2025. I když můžete Visual Studio App Center dál používat, dokud ho úplně nevyřadíte, existuje několik doporučených alternativ, na které můžete migraci zvážit.
Přečtěte si další informace o časových osách a alternativách podpory.
Chybové ukončení App Center automaticky vygeneruje protokol chybových ukončení pokaždé, když dojde k chybě aplikace, a to s protokolem do úložiště zařízení. Když uživatel aplikaci znovu spustí, sada SDK odešle zprávu o chybovém ukončení do App Center. Shromažďování chyb funguje u beta i živých aplikací, to znamená u chybových ukončení odeslaných do Google Play. Protokoly chyb obsahují cenné informace, které vám pomůžou chybu opravit.
Pokud jste v aplikaci ještě nenastavili sadu SDK, postupujte podle pokynů v části Začínáme Unity.
Protokoly chybových ukončení v iOSu vyžadují symboliku. Pokud chcete povolit symboliku, přečtěte si dokumentaci k diagnostice app center, která vysvětluje, jak poskytnout symboly pro vaši aplikaci.
Důležité
Sada SDK pro chyby pro Unity nepodporuje UPW. Pokyny na této stránce se týkají jenom Androidu a iOS.
Poznámka
Sada SDK nepřeposílala žádné protokoly chybových ukončení, pokud jste připojili ladicí program. Ujistěte se, že ladicí program není připojený při chybovém ukončení aplikace.
Poznámka
Pokud jste povolili Enable CrashReport API
playerSettings, sada SDK nebude shromažďovat protokoly chyb.
Chybové ukončení app center poskytuje rozhraní API pro vygenerování testovací chyby pro snadné testování sady SDK. Toto rozhraní API kontroluje konfigurace ladění a verze. Můžete ho tedy použít jenom při ladění, protože nebude fungovat pro aplikace vydané verze.
Crashes.GenerateTestCrash();
Poznámka
Tato metoda bude fungovat pouze se zapnutým nastavením Vývojové sestavení .
Aplikace App Center crashes má dvě rozhraní API, která poskytují další informace pro případ, že dojde k chybě aplikace.
Kdykoli po spuštění sady SDK můžete zkontrolovat, jestli aplikace obdržela upozornění paměti v předchozí relaci:
bool hadLowMemoryWarning = Crashes.HasReceivedMemoryWarningInLastSessionAsync().Result;
Poznámka
Tato metoda nebude fungovat v nástroji Awake()
.
Poznámka
V některých případech zařízení s nedostatkem paměti nemůže odesílat události.
Kdykoli po spuštění sady SDK můžete zkontrolovat, jestli se aplikace při předchozím spuštění chybově ukončila:
bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();
Volání HasCrashedInLastSessionAsync
je užitečné, pokud chcete upravit chování nebo uživatelské rozhraní aplikace po chybovém ukončení. Někteří vývojáři zobrazují další uživatelské rozhraní, aby se omluvili svým uživatelům, nebo se chtějí spojit, když dojde k chybovému ukončení.
Pokud dříve došlo k chybovému ukončení vaší aplikace, můžete získat podrobnosti o posledním chybovém ukončení.
ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();
Nejběžnějším případem použití tohoto rozhraní API je, když uživatel implementuje vlastního delegáta nebo naslouchací proces selhání.
Chybové ukončení app center poskytuje vývojářům zpětná volání, aby mohli před odesláním protokolů o chybách do App Center provést další akce.
Poznámka
Nastavte zpětné volání před spuštěním App Center, například v Awake
metodě, protože App Center začne zpracovávat chyby okamžitě po spuštění.
Nastavte následující zpětné volání, pokud chcete rozhodnout, jestli je potřeba zpracovat konkrétní chybu nebo ne. Může například dojít k chybovému ukončení na úrovni systému, které chcete ignorovat a nechcete ho odesílat do App Center.
Crashes.ShouldProcessErrorReport = (ErrorReport report) =>
{
// Check the report in here and return true or false depending on the ErrorReport.
return true;
};
Pokud je pro vás ochrana osobních údajů uživatelů důležitá, můžete před odesláním zprávy o chybách do App Center získat potvrzení uživatele. Sada SDK zveřejňuje zpětné volání, které informuje o chybovém ukončení app center, aby před odesláním případných zpráv o chybách čekalo na potvrzení uživatele.
Pokud váš kód používá toto zpětné volání, zodpovídáte za získání potvrzení uživatele. Jednou z možností je zobrazení dialogového okna s jednou z následujících možností: Vždy posílat, Posílat a Neodesílat. Na základě zadání sdělíte, co má app center s chybovým ukončením dělat, a chyba se pak bude odpovídajícím způsobem zpracovávat.
Poznámka
V sadě SDK se nezobrazuje dialogové okno, aplikace musí poskytnout vlastní uživatelské rozhraní, které může požádat o souhlas uživatele.
Následující zpětné volání ukazuje, jak říct sadě SDK, aby před odesláním chybových ukončení čekala na potvrzení uživatelem:
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;
};
Pokud zpětné volání vrátí true
, musíte získat oprávnění uživatele a poslat sadě SDK zprávu s výsledkem pomocí následujícího rozhraní API:
// 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);
Jako příklad můžete použít náš příklad vlastního dialogového okna.
Někdy chcete zjistit stav chybového ukončení aplikace. Běžným případem použití je zobrazení uživatelského rozhraní, které uživatele informuje, že aplikace odesílá zprávu o chybách. Dalším scénářem je situace, kdy chcete upravit chování aplikace, abyste měli jistotu, že se protokoly chybových ukončení odesílají krátce po opětovném spuštění. Chybové ukončení App Center nabízí tři různá zpětná volání, která můžete provést, abyste byli informováni o tom, co se stalo:
Crashes.SendingErrorReport += (errorReport) =>
{
// Your code, e.g. to present a custom UI.
};
V případě problémů se sítí nebo výpadkem koncového bodu a vy restartujete aplikaci, SendingErrorReport
se po restartování procesu aktivuje znovu.
Crashes.SentErrorReport += (errorReport) =>
{
// Your code, e.g. to hide the custom UI.
};
Následující zpětné volání se vyvolá, pokud se sadě SDK nepodařilo odeslat protokol chybových ukončení.
Crashes.FailedToSendErrorReport += (errorReport, exception) =>
{
// Your code goes here.
};
Příjem FailedToSendErrorReport
znamená, že došlo k neopravitelné chybě, například k kódu 4xx . Například 401 znamená, že je špatně appSecret
.
Toto zpětné volání se neaktivuje, pokud se jedná o problém se sítí. V tomto případě sada SDK pokračuje v opakování (a také pozastavuje opakování, když je síťové připojení mimo provoz).
Volitelně můžete také přidat binární a textové přílohy k chybovému ukončení nebo neošetřené zprávě o výjimce . Sada SDK je odešle spolu se sestavou, abyste je viděli na portálu App Center. Před odesláním uložené sestavy se vyvolá následující zpětné volání. V případě chybových ukončení k tomu dojde při příštím spuštění aplikace. V případě neošetřených výjimek musíte vyjádřit výslovný souhlas s odesíláním příloh. Ujistěte se, že soubor přílohy nemá název minidump.dmp
, protože tento název je vyhrazený pro soubory s minidumpem. Tady je příklad připojení textu a obrázku k sestavě:
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")
};
};
Chybové ukončení se liší od neošetřených výjimek v sestavách s IsCrash
vlastností . Vlastnost bude mít hodnotu true pro chyby a v opačném případě hodnotu false.
Poznámka
Omezení velikosti příloh je aktuálně 7 MB. Pokus o odeslání větší přílohy způsobí chybu.
Poznámka
GetErrorAttachments
se vyvolá v hlavním vlákně a nerozděluje práci přes rámce. Abyste zabránili blokování herní smyčky, neprovádějte v tomto zpětném volání žádné dlouhotrvající úlohy.
Za běhu můžete povolit a zakázat chybové ukončení app center. Pokud ho zakážete, sada SDK nebude pro aplikaci hlásit žádné chybové ukončení.
Crashes.SetEnabledAsync(false);
Pokud chcete znovu povolit chybové ukončení App Centeru, použijte stejné rozhraní API, ale předejte true
ho jako parametr.
Crashes.SetEnabledAsync(true);
Na toto volání nemusíte čekat, aby byla další volání rozhraní API (například IsEnabledAsync
) konzistentní.
Stav se v úložišti zařízení během spouštění aplikací udržuje.
Můžete také zkontrolovat, jestli je povolená chyba App Center:
bool isEnabled = await Crashes.IsEnabledAsync();
App Center také umožňuje sledovat chyby pomocí zpracovaných výjimek v Unity. K tomu použijte metodu TrackError
:
try {
// your code goes here.
} catch (Exception exception) {
Crashes.TrackError(exception);
}
Pokud chcete získat další kontext chyby, můžete k ní také připojit vlastnosti. Předejte vlastnosti jako slovník řetězců. Tento krok je volitelný.
try {
// your code goes here.
} catch (Exception exception) {
var properties = new Dictionary<string, string>
{
{ "Category", "Music" },
{ "Wifi", "On" }
};
Crashes.TrackError(exception, properties);
}
Volitelně můžete také do sestavy zpracovávané chyby přidat binární a textové přílohy. Předejte přílohy jako pole ErrorAttachmentLog
objektů, jak je znázorněno v následujícím příkladu.
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);
}
Sada App Center SDK ve výchozím nastavení neoznamuje neošetřené výjimky vyvolané ve vaší aplikaci, které nezpůsobí závažné chybové ukončení. Pokud chcete tuto funkci povolit, zavolejte následující metodu:
Crashes.ReportUnhandledExceptions(true);
Po volání tohoto rozhraní API App Center zaznamená všechny neošetřené výjimky jako Problémy na portálu App Center, podobně jako zpracovávané výjimky uvedené výše. Pokud chcete tuto funkci zakázat, zavolejte stejné předávání false
rozhraní API jako parametr.
Crashes.ReportUnhandledExceptions(false);
Poznámka
Některé neošetřené výjimky zjištěné sadou App Center SDK se v uživatelském rozhraní App Center zobrazí jako chyby. Důvodem je to, že Unity ve výchozím nastavení zachytává neošetřené výjimky, což znamená, že aplikace se neukončí a nepovažuje se za chybové ukončení.
Sada App Center SDK ve výchozím nastavení nepovoluje přílohy při neošetřených výjimkách. Pokud chcete tuto funkci povolit, nastavte enableAttachmentsCallback
logický parametr metody na ReportUnhandledExceptions
true
hodnotu :
Crashes.ReportUnhandledExceptions(true, true);
Potom můžete volitelně přidat přílohy do neošetřené sestavy výjimek implementací zpětného volání GetErrorAttachments .
Pokud chcete v App Center dostávat správné zprávy o chybách, nejprve se ujistěte, že máte sadu App Center Crashes SDK nastavenou podle výše uvedených pokynů.
Dále musíte zahrnout a zkompilovat Google Breakpad podle pokynů uvedených v oficiálním souboru README Google Breakpad pro Android. Pokud ho chcete použít v Unity, zahrňte binární soubor do své aplikace.
Poznámka
Sada App Center SDK ve výchozím nastavení neobsahuje sadu Google Breakpad.
Jakmile budete mít Google Breakpad zahrnutý, připojte obslužnou rutinu chyb NDK:
/* Attach NDK Crash Handler. */
var minidumpDir = Crashes.GetMinidumpDirectoryAsync();
setupNativeCrashesListener(minidumpDir.Result);
...
[DllImport("YourLib")]
private static extern void setupNativeCrashesListener(string path);
Metoda setupNativeCrashesListener
je nativní metoda, kterou musíte implementovat v 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);
}
Kde dumpCallback
se používá pro řešení potíží:
/*
* 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;
}
Jakmile jsou tyto metody správně nastavené, aplikace po restartování automaticky odešle minidump do App Center. Při řešení potíží můžete pomocí podrobných protokolů zkontrolovat, jestli se po restartování aplikace odesílají minidumps.
Poznámka
App Center používá rezervovaný název minidump.dmp
pro přílohy minidump. Pokud není soubor minidump, nezapomeňte přílohu pojmenovat jinak, abychom ji mohli správně zpracovat.
Upozornění
V breakpadu je známá chyba, která znemožňuje zachycení chybových ukončení v emulátorech x86.
Další informace o zpracování chybových ukončení najdete v dokumentaci k diagnostice .