Dysfonctionnements d'App Center (Unity)

App Center Crashes génère automatiquement un journal d’incident chaque fois que votre application se bloque, en enregistrant le journal dans le stockage de l’appareil. Lorsqu’un utilisateur redémarre l’application, le Kit de développement logiciel (SDK) envoie le rapport d’incident à App Center. La collecte de plantages fonctionne à la fois pour les applications bêta et en direct, c’est-à-dire les plantages envoyés à Google Play. Les journaux de crash contiennent des informations précieuses pour vous aider à résoudre le crash.

Suivez les instructions de la section Prise en main d’Unity si vous n’avez pas encore configuré le Kit de développement logiciel (SDK) dans votre application.

Les journaux d’incident sur iOS nécessitent une symbolique. Pour activer la symbolique, reportez-vous à la documentation des diagnostics App Center, qui explique comment fournir des symboles pour votre application.

Générer un plantage de test

App Center Crash vous fournit une API pour générer un plantage de test pour faciliter le test du Kit de développement logiciel (SDK). Cette API vérifie les configurations de débogage par rapport aux configurations de production. Vous pouvez donc l’utiliser uniquement lors du débogage, car il ne fonctionnera pas pour les applications de mise en production.

Crashes.GenerateTestCrash();

Obtenir plus d’informations sur un incident précédent

App Center Crash a deux API qui vous donnent plus d’informations au cas où votre application s’est écrasée.

L’application a-t-elle reçu un avertissement de mémoire faible dans la session précédente ?

À tout moment après avoir démarré le Kit de développement logiciel (SDK), vous pouvez vérifier si l’application a reçu un avertissement de mémoire dans la session précédente :

bool hadLowMemoryWarning = Crashes.HasReceivedMemoryWarningInLastSessionAsync().Result;

L’application s’est-elle bloquée dans la session précédente ?

À tout moment après avoir démarré le Kit de développement logiciel (SDK), vous pouvez vérifier si l’application s’est bloquée lors du lancement précédent :

bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();

L’appel HasCrashedInLastSessionAsync est utile si vous souhaitez ajuster le comportement ou l’interface utilisateur de votre application après un incident. Certains développeurs montrent une interface utilisateur supplémentaire pour s’excuser auprès de leurs utilisateurs, ou veulent entrer en contact après un incident.

Détails sur le dernier incident

Si votre application s’est écrasée précédemment, vous pouvez obtenir des détails sur le dernier incident.

ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();

Le cas d’usage le plus courant pour cette API est lorsque un utilisateur implémente son délégué ou écouteur Crash personnalisé.

Personnalisez votre utilisation des pannes d’App Center

App Center Crash fournit des rappels aux développeurs pour effectuer des actions supplémentaires avant et quand ils envoient des journaux d’incident à App Center.

La panne doit-elle être traitée ?

Définissez le rappel suivant si vous souhaitez décider si un incident particulier doit être traité ou non. Par exemple, il peut y avoir un blocage au niveau du système que vous souhaitez ignorer et ne pas envoyer à App Center.

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

Demander le consentement de l’utilisateur pour envoyer un journal d’incident

Si la confidentialité de l’utilisateur est importante pour vous, vous pouvez obtenir la confirmation de l’utilisateur avant d’envoyer un rapport d’incident à App Center. Le Kit de développement logiciel (SDK) expose une fonction de rappel qui indique à App Center Crashes d'attendre la confirmation de l’utilisateur avant d’envoyer tout rapport d’incident.

Si votre code utilise ce rappel, vous êtes responsable de l’obtention de la confirmation de l’utilisateur. Une option consiste à utiliser une invite de dialogue avec l’une des options suivantes : Toujours envoyer, envoyer et ne pas envoyer. En fonction de l’entrée, vous indiquerez à App Center Crashes quoi faire et le plantage sera ensuite géré en conséquence.

Le callback suivant montre comment indiquer à l'SDK d'attendre la confirmation de l'utilisateur avant d'envoyer des pannes :

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;
};

Si le rappel retourne true, vous devez obtenir l’autorisation de l’utilisateur et envoyer un message au Kit de développement logiciel (SDK) avec le résultat à l’aide de l’API suivante :

// 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);

Par exemple, vous pouvez faire référence à notre exemple de dialogue personnalisé.

Obtenir des informations sur l’état d’envoi d’un journal d’incident

Il arrive que vous souhaitiez connaître l'état du crash de votre application. Un cas d’usage courant affiche une interface utilisateur qui informe l’utilisateur que l’application envoie un rapport d’incident. Un autre scénario consiste à ajuster le comportement de l’application pour vous assurer que les journaux de bord des incidents peuvent être soumis peu après la relance. App Center Crash fournit trois rappels différents que vous pouvez faire pour être informé de ce qui a eu lieu :

Le rappel suivant est appelé avant que le SDK envoie un journal d’incident

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

Si nous avons des problèmes réseau ou une panne sur le point de terminaison, et que vous redémarrez l’application, SendingErrorReport elle est déclenchée à nouveau après le redémarrage du processus.

Le rappel suivant sera appelé une fois que le Kit de développement logiciel (SDK) a envoyé un journal d’incident avec succès

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

Le rappel suivant est appelé si le Kit de développement logiciel (SDK) n’a pas pu envoyer un journal d’incident

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

Recevoir FailedToSendErrorReport signifie qu'une erreur non récupérable, telle qu'un code 4xx, s'est produite. Par exemple, 401 signifie que le appSecret est incorrect.

Ce rappel n’est pas déclenché s’il s’agit d’un problème réseau. Dans ce cas, le Kit de développement logiciel (SDK) continue de réessayer (et suspend également les nouvelles tentatives pendant que la connexion réseau est en panne).

Ajouter des pièces jointes à un incident ou un rapport d’exception non géré

Vous pouvez également ajouter des pièces jointes binaires et textuelles à un incident ou à un rapport d’exception non géré . Le Kit de développement logiciel (SDK) les envoie avec le rapport afin que vous puissiez les voir dans le portail App Center. Le rappel suivant est appelé juste avant d’envoyer le rapport stocké. Pour les blocages, cela se produit au prochain lancement de l'application. Pour les exceptions non gérées, vous devez accepter d’envoyer des pièces jointes. Vérifiez que le fichier de pièce jointe n’est pas nommé minidump.dmp car ce nom est réservé aux fichiers minidump. Voici un exemple d’attachement de texte et d’image à un rapport :

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")
    };
};

Les blocages sont différenciés des exceptions non gérées dans les rapports avec la IsCrash propriété. La propriété sera vraie pour les incidents et false dans le cas contraire.

Activer ou désactiver les crashs d’App Center au moment de l'exécution

Vous pouvez activer et désactiver les plantages d'App Center lors de l’exécution. Si vous le désactivez, le Kit de développement logiciel (SDK) n’effectue aucun rapport d’incident pour l’application.

Crashes.SetEnabledAsync(false);

Pour réactiver App Center Plantages, utilisez la même API, mais passez true en tant que paramètre.

Crashes.SetEnabledAsync(true);

Vous n’avez pas besoin d’attendre cet appel pour effectuer d’autres appels d’API (par IsEnabledAsyncexemple) cohérents.

L’état est conservé dans le stockage de l’appareil dans les lancements d’application.

Vérifier si les blocages d’App Center sont activés

Vous pouvez également vérifier si App Center Crashes est activé :

bool isEnabled = await Crashes.IsEnabledAsync();

Exceptions gérées dans Unity

App Center vous permet également de suivre les erreurs à l’aide d’exceptions gérées dans Unity. Pour ce faire, utilisez la TrackError méthode :

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

Pour obtenir un contexte plus approfondi sur votre erreur, vous pouvez également y attacher des propriétés. Transmettez les propriétés sous forme de dictionnaire de chaînes. Cette étape est facultative.

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

Vous pouvez également ajouter éventuellement des pièces jointes binaires et textuelles à un rapport d’erreur géré. Transmettez les pièces jointes en tant que tableau d’objets ErrorAttachmentLog , comme illustré dans l’exemple ci-dessous.

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);
}

Exceptions non gérées dans Unity

Signaler des exceptions non gérées

Par défaut, le Kit de développement logiciel (SDK) App Center ne signale pas les exceptions non gérées survenant dans votre application qui ne provoquent pas un crash fatal. Pour activer cette fonctionnalité, appelez la méthode suivante :

Crashes.ReportUnhandledExceptions(true);

Après avoir appelé cette API, App Center journalise toutes les exceptions non gérées en tant que problèmes dans le portail App Center, comme pour les exceptions gérées mentionnées précédemment. Pour désactiver cette fonctionnalité, appelez la même API en passant false que le paramètre.

Crashes.ReportUnhandledExceptions(false);

Ajouter des pièces jointes à un rapport d’exception non géré

Par défaut, le Kit de développement logiciel (SDK) App Center n’active pas les pièces jointes sur les exceptions non gérées. Pour activer cette fonctionnalité, définissez le enableAttachmentsCallback paramètre booléen de la ReportUnhandledExceptions méthode sur true:

Crashes.ReportUnhandledExceptions(true, true);

Vous pouvez ensuite ajouter des pièces jointes à un rapport d’exception non géré en implémentant le rappel GetErrorAttachments .

Signalement des crashs du NDK

Signalement de pannes

Pour recevoir des rapports d’incident appropriés dans App Center, vérifiez d’abord que le SDK App Center Crashes est configuré en suivant les instructions répertoriées ci-dessus.

Création de la bibliothèque Breakpad

Ensuite, vous devez inclure et compiler Google Breakpad en suivant les instructions répertoriées dans le Google Breakpad officiel pour Android README. Pour l’utiliser dans Unity, incluez le fichier binaire avec votre application.

Attachement du gestionnaire d’exceptions

Une fois que vous avez inclus Google Breakpad, attachez le gestionnaire de crash NDK :

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

...

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

La méthode est une méthode setupNativeCrashesListener native que vous devez implémenter en 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);
}

Où dumpCallback est utilisé pour la résolution des problèmes :

/*
 * 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;
}

Une fois ces méthodes correctement configurées, l’application envoie le minidump à App Center automatiquement lors du redémarrage. Pour résoudre les problèmes, vous pouvez utiliser des journaux détaillés pour vérifier si les minidumps sont envoyés après le redémarrage de l’application.

Symbolique

Pour plus d’informations sur le traitement des incidents, consultez la documentation diagnostics .