Plantages d’App Center (Android)

App Center Crashes génèrera automatiquement un journal des crashs chaque fois que votre application se bloque. Le journal est d’abord écrit dans le stockage de l’appareil et lorsque l’utilisateur redémarre l’application, le rapport d’incident est envoyé à App Center. La collecte de plantages fonctionne à la fois pour les applications bêta et en direct, c’est-à-dire celles soumises à Google Play. Les journaux de crash contiennent des informations précieuses pour vous aider à résoudre le crash.

Suivez la section Prise en main si vous n’avez pas encore configuré le Kit de développement logiciel (SDK) dans 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 ne peut être utilisée que dans les builds de débogage et ne fera rien dans les builds de mise en production.

Crashes.generateTestCrash();

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 :

Crashes.hasReceivedMemoryWarningInLastSession();

Crashes.hasReceivedMemoryWarningInLastSession()

Cette API est asynchrone, vous pouvez en savoir plus sur cela dans notre guide des API asynchrones App Center .

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 :

Crashes.hasCrashedInLastSession();

Crashes.hasCrashedInLastSession()

Cette API est asynchrone, vous pouvez en savoir plus sur cela dans notre guide des API asynchrones App Center .

Cela est pratique si vous souhaitez ajuster le comportement ou l’interface utilisateur de votre application une fois qu’un incident s’est produit. Certains développeurs ont choisi d’afficher une interface utilisateur supplémentaire pour s’excuser auprès de leurs utilisateurs ou de vouloir 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.

Crashes.getLastSessionCrashReport();

Crashes.getLastSessionCrashReport()

Cette API est asynchrone, vous pouvez en savoir plus sur cela dans notre guide des API asynchrones App Center .

Il existe de nombreux cas d'utilisation pour cette API, le plus courant est celui des personnes qui appellent cette API et implémentent leur CrashesListener 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 lors de l’envoi de journaux d’incident à App Center.

Pour gérer les rappels, implémentez toutes les méthodes de l’interface CrashesListener ou remplacez la AbstractCrashesListener classe et choisissez uniquement celles qui vous intéressent.

Utilisez votre propre CrashesListener

Créez votre propre CrashListener et attribuez-le comme suit :

CrashesListener customListener = new CrashesListener() {
    // Implement all callbacks here.
};
Crashes.setListener(customListener);

val customListener = object : CrashesListener {
    // Implement all callbacks here.
}
Crashes.setListener(customListener)

Si vous n’êtes intéressé que par la personnalisation de certains rappels, utilisez plutôt :AbstractCrashesListener

AbstractCrashesListener customListener = new AbstractCrashesListener() {
    // Implement any callback here as required.
};
Crashes.setListener(customListener);

val customListener = object : AbstractCrashesListener() {
    // Implement any callback here as required.
}
Crashes.setListener(customListener)

La panne doit-elle être traitée ?

Implémentez ce rappel 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 que vous ne souhaitez pas envoyer à App Center.

@Override
public boolean shouldProcess(ErrorReport report) {
    return true; // return true if the crash report should be processed, otherwise false.
}

override fun shouldProcess(report: ErrorReport?): Boolean {
    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 vous avez choisi de le faire, vous êtes responsable de l’obtention de la confirmation de l’utilisateur, par exemple via une invite de dialogue avec l’une des options suivantes : Toujours envoyer, envoyer et ne pas envoyer. En fonction des données fournies, vous allez indiquer à App Center Crashes ce qu’il doit 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 :

@Override
public boolean 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;
}

override fun shouldAwaitUserConfirmation(): Boolean {
    return true
}

Si vous retournez true, votre application doit obtenir (à l’aide de votre propre code) 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(Crashes.DONT_SEND);
Crashes.notifyUserConfirmation(Crashes.SEND);
Crashes.notifyUserConfirmation(Crashes.ALWAYS_SEND);

Crashes.notifyUserConfirmation(Crashes.DONT_SEND)
Crashes.notifyUserConfirmation(Crashes.SEND)
Crashes.notifyUserConfirmation(Crashes.ALWAYS_SEND)

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 est que vous souhaiterez peut-être afficher l’interface utilisateur qui indique aux utilisateurs que votre application envoie un rapport d’incident ou, si votre application se bloque rapidement après le lancement, vous souhaitez ajuster le comportement de l’application pour vous assurer que les journaux d’incident peuvent être soumis. App Center Crash a trois rappels différents que vous pouvez utiliser dans votre application pour être informé de ce qui se passe :

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

@Override
public void onBeforeSending(ErrorReport errorReport) {
    // Your code, e.g. to present a custom UI.
}

override fun onBeforeSending(report: 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, onBeforeSending 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

@Override
public void onSendingSucceeded(ErrorReport report) {
    // Your code, e.g. to hide the custom UI.
}

override fun onSendingSucceeded(report: ErrorReport?) {
    // Your code, e.g. to hide the custom UI.
}

Le rappel suivant est appelé si le SDK n’a pas pu envoyer un journal d’incident

@Override
public void onSendingFailed(ErrorReport report, Exception e) {
    // Your code goes here.
}

override fun onSendingFailed(report: ErrorReport?, e: Exception?) {
    // Your code goes here.
}

Recevoir onSendingFailed 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 rapport d’incident

Vous pouvez ajouter des pièces jointes binaires et textuelles à un rapport de plantage. Le SDK les enverra avec le rapport de plantage afin que vous puissiez les voir dans le portail App Center. Le callback suivant sera invoqué juste avant d’envoyer le crash stocké suite aux lancements précédents de l’application. Il ne sera pas appelé lorsque la panne se produit. 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 de comment joindre du texte et une image à un incident :

@Override
public Iterable<ErrorAttachmentLog> getErrorAttachments(ErrorReport report) {

    // Attach some text.
    ErrorAttachmentLog textLog = ErrorAttachmentLog.attachmentWithText("This is a text attachment.", "text.txt");

    // Attach binary data.
    byte[] binaryData = getYourBinary();
    ErrorAttachmentLog binaryLog = ErrorAttachmentLog.attachmentWithBinary(binaryData, "your_filename.jpeg", "image/jpeg");

    // Return attachments as list.
    return Arrays.asList(textLog, binaryLog);
}

override fun getErrorAttachments(report: ErrorReport?): MutableIterable<ErrorAttachmentLog> {

    // Attach some text.
    val textLog = ErrorAttachmentLog.attachmentWithText("This is a text attachment.", "text.txt")

    // Attach binary data.
    val binaryData = getYourBinary()
    val binaryLog = ErrorAttachmentLog.attachmentWithBinary(binaryData, "your_filename.jpeg", "image/jpeg")

    // Return attachments as list.
    return listOf(textLog, binaryLog)
}

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) ne produit aucun rapport d’incident pour l’application.

Crashes.setEnabled(false);

Crashes.setEnabled(false)

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

Crashes.setEnabled(true);

Crashes.setEnabled(true)

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

Cette API est asynchrone, vous pouvez en savoir plus sur cela dans notre guide des API asynchrones App Center .

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

Vous pouvez également vérifier si les crashs d'App Center sont activé ou non.

Crashes.isEnabled();

Crashes.isEnabled()

Cette API est asynchrone, vous pouvez en savoir plus sur cela dans notre guide des API asynchrones App Center .

Erreurs gérées

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

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

try {
    // your code goes here.
} catch (exception: Exception) {
    Crashes.trackError(exception)
}

Une application peut éventuellement attacher des propriétés à un rapport d’erreurs géré pour fournir un contexte supplémentaire. Transmettez les propriétés sous la forme d’une carte de paires clé/valeur (chaînes uniquement) comme indiqué dans l’exemple ci-dessous.

try {
    // your code goes here.
} catch (Exception exception) {
    Map<String, String> properties = new HashMap<String, String>() {{
        put("Category", "Music");
        put("Wifi", "On");
    }};
    Crashes.trackError(exception, properties, null);
}

try {
    // your code goes here.
} catch (exception: Exception) {
    val properties = mapOf("Category" to "Music", "Wifi" to "On")
    Crashes.trackError(exception, properties, null)
}

Vous pouvez également ajouter éventuellement des pièces jointes binaires et textuelles à un rapport d’erreur géré. Transmettez les pièces jointes comme Iterable, cela est indiqué dans l’exemple ci-dessous.

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

    // Attach some text.
    ErrorAttachmentLog textLog = ErrorAttachmentLog.attachmentWithText("This is a text attachment.", "text.txt");

    // Attach binary data.
    byte[] binaryData = getYourBinary();
    ErrorAttachmentLog binaryLog = ErrorAttachmentLog.attachmentWithBinary(binaryData, "your_filename.jpeg", "image/jpeg");

    // Track an exception with attachments.
    Crashes.trackError(exception, null, Arrays.asList(textLog, binaryLog));
}

try {
    // your code goes here.
} catch (exception: Exception) {

    // Attach some text.
    val textLog = ErrorAttachmentLog.attachmentWithText("This is a text attachment.", "text.txt")

    // Attach binary data.
    val binaryData = getYourBinary()
    val binaryLog = ErrorAttachmentLog.attachmentWithBinary(binaryData, "your_filename.jpeg", "image/jpeg")

    // Track an exception with attachments.
    Crashes.trackError(exception, null, listOf(textLog, binaryLog))
}

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, incluez et compilez Google Breakpad en suivant les instructions répertoriées dans le README officiel de Google Breakpad pour Android.

Attachement du gestionnaire d’exceptions

Une fois que vous avez Google Breakpad inclus, attachez le gestionnaire de crash NDK après AppCenter.start:

// Attach NDK Crash Handler after SDK is initialized.
Crashes.getMinidumpDirectory().thenAccept(new AppCenterConsumer<String>() {
    @Override
    public void accept(String path) {

        // Path is null when Crashes is disabled.
        if (path != null) {
            setupNativeCrashesListener(path);
        }
    }
});

La méthode est une méthode setupNativeCrashesListener native que vous devez implémenter en C/C++ :

#include "google-breakpad/src/client/linux/handler/exception_handler.h"
#include "google-breakpad/src/client/linux/handler/minidump_descriptor.h"

void Java_com_microsoft_your_package_YourActivity_setupNativeCrashesListener(
        JNIEnv *env, jobject, jstring path) {
    const char *dumpPath = (char *) env->GetStringUTFChars(path, NULL);
    google_breakpad::MinidumpDescriptor descriptor(dumpPath);
    new google_breakpad::ExceptionHandler(descriptor, NULL, dumpCallback, NULL, true, -1);
    env->ReleaseStringUTFChars(path, dumpPath);
}

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.
 */
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 (AppCenter.setLogLevel(Log.VERBOSE) avant AppCenter.start) 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 .