Partilhar via


Centro de Aplicações falhas (Unity)

Importante

O Visual Studio App Center foi desativado em 31 de março de 2025, exceto para os recursos de Análise e Diagnóstico, que continuarão a ter suporte até 30 de junho de 2026. Mais informações.

O App Center Crashes gera automaticamente um registo de falhas sempre que a sua aplicação falha, gravando-o na armazenamento do dispositivo. Quando um usuário inicia o aplicativo novamente, o SDK envia o relatório de falhas para o App Center. A coleta de falhas funciona tanto para aplicativos beta quanto para aplicativos ao vivo, ou seja, falhas enviadas ao Google Play. Os registos de falhas contêm informações valiosas para ajudar a corrigir a falha.

Siga as instruções na seção Introdução ao Unity se ainda não configurou o SDK em seu aplicativo.

Os registos de falhas no iOS requerem Simbolização. Para habilitar a simbologia, consulte a documentação do Diagnóstico do App Center, que explica como fornecer símbolos para seu aplicativo.

Importante

O SDK de Crashes para Unity não suporta UWP. As instruções nesta página abrangem apenas Android e iOS.

Observação

O SDK não encaminhará nenhum log de falhas se você tiver anexado o depurador. Certifique-se de que o depurador não está ligado quando se fizer crash a aplicação.

Observação

Se você tiver Enable CrashReport API ativado em PlayerSettings, o SDK não coletará logs de falhas.

Gerar uma falha de teste

O App Center Crashes fornece uma API para gerar uma falha de teste para facilitar o teste do SDK. Esta API verifica se há configurações de depuração vs versão. Portanto, você só pode usá-lo durante a depuração, pois não funcionará para aplicativos de lançamento.

Crashes.GenerateTestCrash();

Observação

Esse método só funcionará com a configuração Development Build ativada.

Obter mais informações sobre uma falha anterior

O App Center Crashes tem duas APIs que fornecem mais informações caso seu aplicativo tenha falhado.

O aplicativo recebeu um aviso de falta de memória na sessão anterior?

A qualquer momento depois de iniciar o SDK, você pode verificar se o aplicativo recebeu um aviso de memória na sessão anterior:

bool hadLowMemoryWarning = Crashes.HasReceivedMemoryWarningInLastSessionAsync().Result;

Observação

Este método não funcionará no Awake().

Observação

Em alguns casos, um dispositivo com pouca memória não pode enviar eventos.

O aplicativo travou na sessão anterior?

A qualquer momento depois de iniciar o SDK, você pode verificar se o aplicativo falhou na inicialização anterior:

bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();

A chamada HasCrashedInLastSessionAsync é útil se você quiser ajustar o comportamento ou a interface do usuário do seu aplicativo após a ocorrência de uma falha. Alguns desenvolvedores mostram uma interface do usuário adicional para pedir desculpas aos usuários ou querem entrar em contato após a ocorrência de uma falha.

Detalhes sobre o último acidente

Se o seu aplicativo travou anteriormente, você pode obter detalhes sobre a última falha.

ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();

O caso de uso mais comum para essa API é quando um usuário está implementando seu delegado ou ouvinte personalizado de Falhas.

Personalize o uso do App Center Crashes

O App Center Crashes fornece callbacks para que os desenvolvedores tomem ações adicionais antes de e quando enviarem logs de falhas para o App Center.

Observação

Defina o retorno de chamada antes que o App Center seja iniciado. Por exemplo, no método Awake, já que o App Center inicia o processamento de falhas imediatamente após o início.

O acidente deve ser processado?

Defina o seguinte callback se quiser decidir se uma falha específica precisa ser processada ou não. Por exemplo, pode haver uma falha no nível do sistema que você deseja ignorar e não enviar para o App Center.

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

Se a privacidade do usuário for importante para você, convém obter a confirmação do usuário antes de enviar um relatório de falhas para o App Center. O SDK expõe um callback que indica ao App Center Crashes para aguardar a confirmação do utilizador antes de enviar qualquer relatório de falhas.

Se o teu código usar este callback, serás responsável por obter a confirmação do utilizador. Uma opção é através de um prompt de diálogo com uma das seguintes opções: Sempre enviar, Enviar e Não enviar. Com base na entrada, você informará ao App Center Crashes o que fazer e a falha será tratada de acordo.

Observação

O SDK não exibe uma caixa de diálogo para isso, o aplicativo deve fornecer sua própria interface do usuário para solicitar o consentimento do usuário.

O seguinte callback mostra como instruir o SDK a esperar pela confirmação do usuário antes de enviar crashes:

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

Se o retorno de chamada retornar true, você deverá obter permissão de usuário e enviar uma mensagem ao SDK com o resultado usando a seguinte 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);

Como exemplo, você pode consultar nosso exemplo de diálogo personalizado.

Obter informações sobre o estado de envio de um registo de falhas

Às vezes, você quer saber o status da falha do seu aplicativo. Um caso de uso comum é a exibição de uma interface do usuário que informa ao usuário que o aplicativo está enviando um relatório de falhas. Outro cenário é quando você deseja ajustar o comportamento do aplicativo para garantir que os logs de falhas possam ser enviados logo após a reinicialização. O App Center Crashes fornece três retornos de chamada diferentes que você pode fazer para ser notificado do que aconteceu:

O seguinte callback será invocado antes que o SDK envie um registo de falhas

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

No caso de termos problemas de rede ou uma interrupção no ponto de extremidade, e você reiniciar o aplicativo, SendingErrorReport é acionado novamente após a reinicialização do processo.

A função de retorno seguinte será invocada depois do SDK enviar com sucesso um relatório de falhas.

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

O seguinte callback irá ser invocado se o SDK não tiver conseguido enviar um registo de falhas.

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

Receber FailedToSendErrorReport significa que ocorreu um erro não recuperável, como ocorreu um código 4xx . Por exemplo, 401 significa que o appSecret está errado.

Esse retorno de chamada não é acionado se for um problema de rede. Nesse caso, o SDK continua tentando novamente (e também pausa novas tentativas enquanto a conexão de rede está inativa).

Adicionar anexos a uma falha de sistema ou a um relatório de exceção não tratada

Opcionalmente, você também pode adicionar anexos binários e de texto a uma falha ou a um relatório de exceção sem tratamento . O SDK irá enviá-los junto com o relatório para que você possa vê-los no portal do App Center. A função de retorno a seguir será invocada mesmo antes de enviar o relatório armazenado. Na ocorrência de falhas, isto acontece na próxima vez que a aplicação é iniciada. Para exceções não tratadas, você deve optar por enviar anexos. Certifique-se de que o arquivo anexo não é nomeado minidump.dmp , pois esse nome está reservado para arquivos minidump. Aqui está um exemplo de como anexar texto e uma imagem a um relatório:

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

As falhas são diferenciadas de exceções não tratadas em relatórios com a IsCrash propriedade. A propriedade será verdadeira para erros e falsa caso contrário.

Observação

O limite de tamanho é para anexos atualmente 7 MB. A tentativa de enviar um anexo maior desencadeará um erro.

Observação

GetErrorAttachments é invocado no thread principal e não divide o trabalho em quadros. Para evitar bloquear o ciclo de jogo, não execute nenhuma tarefa de longa duração nesta função de retorno.

Ativar ou desativar falhas do App Center em tempo de execução

Você pode habilitar e desabilitar a funcionalidade Crashes do App Center em tempo de execução. Se você desativá-lo, o SDK não executará nenhum relatório de falhas para o aplicativo.

Crashes.SetEnabledAsync(false);

Para habilitar as falhas do App Center novamente, use a mesma API, mas passe true como parâmetro.

Crashes.SetEnabledAsync(true);

Você não precisa esperar essa chamada para tornar outras chamadas de API (como IsEnabledAsync) consistentes.

O estado é persistido no armazenamento do dispositivo em todas as inicializações de aplicativos.

Verifique se o App Center Crashes está ativado

Você também pode verificar se o App Center Crashes está ativado:

bool isEnabled = await Crashes.IsEnabledAsync();

Exceções tratadas no Unity

O App Center também permite que você rastreie erros usando exceções manipuladas no Unity. Para fazer isso, use o TrackError método:

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

Para obter mais contexto sobre seu erro, você também pode anexar propriedades a ele. Passe as propriedades como um dicionário de cadeias de caracteres. Esta etapa é opcional.

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

Opcionalmente, você também pode adicionar anexos binários e de texto a um relatório de erro manipulado. Passe os anexos como uma matriz de ErrorAttachmentLog objetos, conforme mostrado no exemplo abaixo.

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

Exceções não tratadas no Unity

Comunicar exceções não tratadas

Por padrão, o SDK do App Center não reporta exceções não tratadas que ocorram na sua aplicação e que não causem uma falha fatal. Para habilitar essa funcionalidade, chame o seguinte método:

Crashes.ReportUnhandledExceptions(true);

Depois de chamar essa API, o App Center registra todas as exceções não tratadas como Problemas no portal do App Center, semelhante às exceções tratadas mencionadas anteriormente. Para desativar esta funcionalidade, chame a mesma API passando false como parâmetro.

Crashes.ReportUnhandledExceptions(false);

Observação

Algumas exceções não tratadas detetadas pelo SDK do App Center aparecerão como erros na interface do usuário do App Center. Isso ocorre porque o Unity captura exceções não tratadas por padrão, o que significa que o aplicativo não sai e não é considerado uma falha.

Adicionar anexos a um relatório de exceções sem tratamento

Por padrão, o SDK do App Center não habilita anexos em exceções não tratadas. Para habilitar essa funcionalidade, defina o enableAttachmentsCallbackReportUnhandledExceptions parâmetro booleano do método como true:

Crashes.ReportUnhandledExceptions(true, true);

Em seguida, pode adicionar, opcionalmente, anexos a um relatório de exceção não tratada ao implementar a função de retorno de chamada GetErrorAttachments.

Relatando falhas de NDK

Comunicar falhas

Para receber relatórios de falhas adequados no App Center, primeiro certifique-se de ter o SDK de falhas do App Center configurado seguindo as instruções listadas acima.

Construção da biblioteca Breakpad

Em seguida, você deve incluir e compilar o Google Breakpad seguindo as instruções listadas no Google Breakpad oficial para Android README. Para usá-lo no Unity, inclua o binário em seu aplicativo.

Observação

O SDK do App Center não agrupa o Google Breakpad por padrão.

Anexando o manipulador de exceção

Depois de incluir o Google Breakpad, anexe o NDK Crash Handler:

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

...

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

O método setupNativeCrashesListener é um método nativo que você deve implementar em 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);
}

Onde dumpCallback é usado para solução de problemas:

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

Depois que esses métodos estiverem configurados corretamente, o aplicativo envia o minidump para o App Center automaticamente após a reinicialização. Para solucionar problemas, você pode usar logs detalhados para verificar se minidumps são enviados depois que o aplicativo é reiniciado.

Observação

O App Center usa o nome minidump.dmp reservado para anexos de minidump. Certifique-se de dar ao seu anexo um nome diferente, a menos que seja um arquivo minidump para que possamos manipulá-lo corretamente.

Advertência

Há um bug conhecido no breakpad que torna impossível capturar falhas em emuladores x86.

Simbologia

Consulte a documentação de Diagnóstico para obter mais informações sobre o processamento de falhas.