Arresti anomali di App Center (MAUI e Xamarin)

Gli arresti anomali di App Center genereranno automaticamente un log di arresto anomalo ogni volta che l'app si arresta in modo anomalo. Il log viene prima scritto nella risorsa di archiviazione del dispositivo e quando l'utente avvia nuovamente l'app, il report di arresto anomalo verrà inviato ad App Center. La raccolta di arresti anomali funziona sia per le app beta che per quelle attive, ovvero quelle inviate al App Store. I log di arresto anomalo contengono informazioni utili per risolvere l'arresto anomalo del sistema.

Se non è ancora stato configurato l'SDK nell'applicazione, seguire la sezione Introduzione.

Inoltre, i log di arresto anomalo in iOS richiedono simbolicamente, vedere la documentazione di Diagnostica di App Center che spiega come fornire simboli per l'app.

Nota

In iOS e Mac l'SDK non salverà alcun log di arresto anomalo se è stato collegato un debugger. Assicurarsi che il debugger non sia collegato quando si arresta l'arresto anomalo dell'app iOS e macOS. In Android è possibile arrestare l'arresto anomalo durante la connessione del debugger, ma è necessario continuare l'esecuzione dopo l'interruzione nell'eccezione non gestita.

Generare un arresto anomalo del test

Gli arresti anomali di App Center offrono un'API per generare un arresto anomalo del test per semplificare il test dell'SDK. Questa API verifica la presenza di configurazioni di debug e versione. È quindi possibile usarlo solo durante il debug perché non funzionerà per le app di rilascio.

Crashes.GenerateTestCrash();

Ottenere altre informazioni su un arresto anomalo precedente

Gli arresti anomali di App Center hanno due API che forniscono altre informazioni in caso di arresto anomalo dell'app.

L'app ha ricevuto un avviso di memoria insufficiente nella sessione precedente?

In qualsiasi momento dopo l'avvio dell'SDK, è possibile verificare se l'app ha ricevuto un avviso di memoria nella sessione precedente:

bool hadMemoryWarning = await Crashes.HasReceivedMemoryWarningInLastSessionAsync();

Nota

Questo metodo deve essere utilizzato solo dopo Crashes l'avvio, ma restituirà false sempre prima dell'avvio.

Nota

In alcuni casi, un dispositivo con memoria insufficiente non può inviare eventi.

L'arresto anomalo dell'app nella sessione precedente?

In qualsiasi momento dopo l'avvio dell'SDK, è possibile verificare se l'app si è arrestata in modo anomalo nell'avvio precedente:

bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();

Questo è utile nel caso in cui vuoi modificare il comportamento o l'interfaccia utente della tua app dopo che si è verificato un arresto anomalo. Alcuni sviluppatori scelgono di mostrare un'interfaccia utente aggiuntiva per scusarsi con gli utenti o desiderano un modo per entrare in contatto dopo che si è verificato un arresto anomalo.

Nota

Questo metodo deve essere utilizzato solo dopo Crashes l'avvio, ma restituirà false sempre prima dell'avvio.

Dettagli sull'ultimo arresto anomalo

Se l'app si è arrestata in modo anomalo in precedenza, è possibile ottenere informazioni dettagliate sull'ultimo arresto anomalo.

ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();

Nota

Questo metodo deve essere utilizzato solo dopo Crashes l'avvio, ma restituirà null sempre prima dell'avvio.

Esistono numerosi casi d'uso per questa API, quello più comune è rappresentato dalle persone che chiamano questa API e implementano il delegato o il listener di arresti anomali personalizzati.

Personalizzare l'utilizzo degli arresti anomali di App Center

Gli arresti anomali di App Center offrono callback che consentono agli sviluppatori di eseguire azioni aggiuntive prima e quando si inviano log di arresto anomalo ad App Center.

Nota

Impostare il callback prima di chiamare AppCenter.Start(), poiché App Center avvia l'elaborazione si arresta in modo anomalo immediatamente dopo l'avvio.

L'arresto anomalo deve essere elaborato?

Impostare questo callback se si vuole decidere se un determinato arresto anomalo deve essere elaborato o meno. Ad esempio, potrebbe verificarsi un arresto anomalo a livello di sistema che si vuole ignorare e che non si vuole inviare ad App Center.

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

Se la privacy dell'utente è importante per te, potresti voler ricevere una conferma dell'utente prima di inviare un report di arresto anomalo al Centro app. L'SDK espone un callback che indica agli arresti anomali di App Center di attendere la conferma dell'utente prima di inviare eventuali segnalazioni di arresto anomalo.

Se si sceglie di farlo, si è responsabili di ottenere la conferma dell'utente, ad esempio tramite una richiesta di dialogo con una delle opzioni seguenti: Invia sempre, Invia e Non inviare. In base all'input, si indicherà agli arresti anomali di App Center cosa fare e l'arresto anomalo verrà quindi gestito di conseguenza.

Nota

L'SDK non visualizza una finestra di dialogo per questa operazione, l'app deve fornire la propria interfaccia utente per richiedere il consenso dell'utente.

Nota

L'app non deve chiamare NotifyUserConfirmation in modo esplicito se non implementa una finestra di dialogo di conferma dell'utente. Il modulo Arresti anomali gestirà l'invio implicito dei log.

Il callback seguente illustra come indicare all'SDK di attendere la conferma dell'utente prima di inviare arresti anomali:

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

Nel caso in cui venga restituito true il callback precedente, l'app deve ottenere (usando il proprio codice) l'autorizzazione utente e inserire un messaggio all'SDK con il risultato usando l'API seguente.

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

Ad esempio, è possibile fare riferimento all'esempio di dialogo personalizzato.

Ottenere informazioni sullo stato di invio per un log di arresto anomalo

A volte, vuoi conoscere lo stato dell'arresto anomalo dell'app. Un caso d'uso comune è che potresti voler mostrare all'interfaccia utente che indica agli utenti che l'app sta inviando un report di arresto anomalo o, nel caso in cui l'app si arresti in modo anomalo dopo l'avvio, vuoi modificare il comportamento dell'app per assicurarti che i log di arresto anomalo possano essere inviati. Gli arresti anomali di App Center offrono tre callback diversi che è possibile usare nell'app per ricevere una notifica di cosa sta succedendo:

Il callback seguente verrà richiamato prima che l'SDK invii un log di arresto anomalo

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

In caso di problemi di rete o interruzione dell'endpoint e il riavvio dell'app viene SendingErrorReport attivato di nuovo dopo il riavvio del processo.

Il callback seguente verrà richiamato dopo che l'SDK ha inviato correttamente un log di arresto anomalo

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

Il callback seguente verrà richiamato se l'SDK non è riuscito a inviare un log di arresto anomalo

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

La ricezione FailedToSendErrorReport indica che si è verificato un errore non recuperabile, ad esempio un codice 4xx . Ad esempio, 401 indica che l'errore appSecret è.

Questo callback non viene attivato se si tratta di un problema di rete. In questo caso, l'SDK continua a ritentare (e sospende anche i tentativi mentre la connessione di rete è inattiva).

Aggiungere allegati a un report di arresto anomalo

È possibile aggiungere allegati binari e di testo a un report di arresto anomalo del sistema. L'SDK li invierà insieme all'arresto anomalo in modo da poterli visualizzare nel portale di App Center. Il callback seguente verrà richiamato immediatamente prima di inviare l'arresto anomalo archiviato dall'avvio dell'applicazione precedente. Non verrà richiamato quando si verifica l'arresto anomalo. Assicurarsi che il file allegato non sia denominato minidump.dmp in quanto tale nome è riservato per i file minidump. Ecco un esempio di come allegare testo e un'immagine a un arresto anomalo:

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

Nota

Il limite di dimensioni è attualmente 7 MB. Se si tenta di inviare un allegato più grande, verrà generato un errore.

Abilitare o disabilitare arresti anomali di App Center in fase di esecuzione

È possibile abilitare e disabilitare arresti anomali di App Center in fase di esecuzione. Se la si disabilita, l'SDK non eseguirà alcuna segnalazione di arresto anomalo per l'app.

Crashes.SetEnabledAsync(false);

Per abilitare di nuovo gli arresti anomali di App Center, usare la stessa API ma passare true come parametro.

Crashes.SetEnabledAsync(true);

Non è necessario attendere questa chiamata per rendere coerenti altre chiamate API ( ad esempio IsEnabledAsync).

Lo stato viene salvato in modo permanente nella risorsa di archiviazione del dispositivo tra i lanci dell'applicazione.

Nota

Questo metodo deve essere utilizzato solo dopo Crashes l'avvio.

Controllare se Gli arresti anomali di App Center sono abilitati

È anche possibile verificare se Gli arresti anomali di App Center sono abilitati o meno:

bool isEnabled = await Crashes.IsEnabledAsync();

Nota

Questo metodo deve essere utilizzato solo dopo Crashes l'avvio, ma restituirà false sempre prima dell'avvio.

Errori gestiti

App Center consente anche di tenere traccia degli errori usando le eccezioni gestite. A tale scopo, usare il TrackError metodo :

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

Un'app può facoltativamente allegare proprietà a una segnalazione degli errori gestita per fornire ulteriore contesto. Passare le proprietà come dizionario di coppie chiave/valore (solo stringhe), come illustrato nell'esempio seguente.

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

È anche possibile aggiungere allegati binari e di testo a un report degli errori gestito. Passare gli allegati come matrice di ErrorAttachmentLog oggetti, come illustrato nell'esempio seguente.

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