Solução de problemas e perguntas frequentes sobre o Crashlytics

Formatos diferentes (às vezes, "variantes") para alguns problemas na tabela Problemas

Talvez sejam exibidos dois formatos diferentes para os problemas listados na tabela Problemas no console do Firebase. Pode ser que você também se depare com um recurso chamado "variantes" em alguns dos seus problemas. Confira abaixo porque isso acontece.

No início de 2023, lançamos um mecanismo de análise aprimorado para agrupar eventos, além de um design atualizado e alguns recursos avançados para novos problemas, como variantes. Confira nossa última postagem do blog para saber de todos os detalhes ou confira os destaques abaixo.

O Crashlytics analisa todos os eventos do seu app (como falhas, erros não fatais e ANRs) e cria grupos de eventos chamados problemas. Todos os eventos de um problema têm um ponto de falha comum.

Para agrupar eventos nesses problemas, o mecanismo de análise aprimorado analisa muitos aspectos do evento, incluindo os frames no stack trace, a mensagem de exceção, o código do erro e outras características da plataforma ou do tipo de erro.

No entanto, dentro de um grupo de eventos, os stack traces que levam à falha podem ser diferentes. Um stack trace diferente pode significar uma causa raiz diferente. Para representar essa possível diferença em um problema, agora criamos variantes. Cada variante é um subgrupo de eventos em um problema que tem o mesmo ponto de falha e um stack trace semelhante. Com as variantes, é possível depurar os stack traces mais comuns em um problema e determinar se diferentes causas raiz estão causando a falha.

Confira o que mudou com essas melhorias:

• Metadados reformulados na linha do problema
  Agora ficou mais fácil entender e filtrar problemas no seu app.

• Menos problemas duplicados
  Uma mudança no número da linha não resulta em um novo problema.

• Depuração mais fácil de problemas complexos com várias causas raiz
  Use variantes para depurar os stack traces mais comuns em um problema.

• Alertas e indicadores mais significativos
  Um novo problema representa um novo bug.

• Pesquisa mais avançada
  Cada problema contém metadados mais pesquisáveis, como tipo de exceção e nome do pacote.

Confira como essas melhorias estão sendo lançadas:

• Quando novos eventos do seu app são recebidos, verificamos se eles correspondem a um problema existente.

• Se não houver correspondência, vamos aplicar automaticamente ao evento nosso algoritmo de agrupamento de eventos mais inteligente e criaremos um novo problema com o design de metadados reformulado.

Essa é a primeira grande atualização que estamos fazendo no nosso agrupamento de eventos. Se você tiver feedback ou encontrar algum problema, preencha um relatório.

Não há registros de navegação estrutural

Se você não estiver vendo registros de navegação estrutural (iOS+ | Android | Flutter | Unity), confira a configuração do Google Analytics no seu app. Verifique se você atende aos seguintes requisitos:

• Você ativou o Google Analytics no seu projeto do Firebase.

• Você ativou o Compartilhamento de dados para Google Analytics. Saiba mais sobre essa configuração em Gerenciar as configurações de compartilhamento de dados do Analytics

• Você adicionou ao seu app o SDK do Firebase para Google Analytics: iOS+ | Android | Flutter | Unity.
  Esse SDK precisa ser adicionado além do SDK do Crashlytics.

• Você está usando as versões mais recentes do SDK do Firebase para todos os produtos que usa no seu app (iOS+ | Android | Flutter | Unity).

  Para plataformas da Apple e apps Android, verifique principalmente se você está usando pelo menos as seguintes versões do SDK do Firebase para Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ para macOS e tvOS) | Android — v17.2.3+ (BoM v24.7.1+).

Não há alertas de velocidade

Se você não estiver recebendo alertas de velocidade, verifique se está usando o SDK do Crashlytics 11.7.0+.

As métricas sem falhas não aparecem (ou aparecem métricas não confiáveis)

Se você não estiver vendo métricas sem falhas (como usuários e sessões sem falhas) ou métricas não confiáveis, verifique o seguinte:

• Verifique se você está usando o SDK do Crashlytics 11.7.0 ou mais recente.

• Verifique se as configurações de coleta de dados não estão afetando a qualidade das métricas sem falhas:

  • Se você ativar a geração de relatórios desativando os relatórios automáticos de erros, as informações de falhas só poderão ser enviadas para Crashlytics de usuários que aceitaram explicitamente a coleta de dados. Assim, a precisão das métricas sem falhas será afetada, já que Crashlytics só tem informações de falhas desses usuários (em vez de todos). Isso significa que as métricas sem falhas podem ser menos confiáveis e menos representativas da estabilidade geral do app.

  • Se a coleta automática de dados estiver desativada, use sendUnsentReports para enviar relatórios em cache no dispositivo para Crashlytics. O uso desse método vai enviar dados de crash para Crashlytics, mas não dados de sessões, o que faz com que os gráficos do console mostrem valores baixos ou zero para métricas sem falhas.

Como a porcentagem de usuários sem falhas é calculada?

Consulte Noções básicas sobre métricas sem falhas.

Quem pode ver, escrever e excluir notas sobre um problema?

Com as observações, os membros do projeto podem comentar sobre problemas específicos com perguntas, atualizações de status etc.

Quando um membro do projeto posta uma observação, ela é marcada com o e-mail da Conta do Google. Esse endereço de e-mail e as notas ficam visíveis para todos os membros do projeto com acesso de visualização.

Veja a seguir o acesso necessário para visualizar, gravar e excluir observações:

• Os membros do projeto com qualquer um dos papéis a seguir podem ver e excluir as notas existentes, além de escrever novas notas sobre um problema.

  • Proprietário ou editor do projeto, administrador do Firebase, administrador de qualidade ou administrador do Crashlytics

• Os membros do projeto com qualquer um dos papéis a seguir podem ver as notas postadas em um problema, mas não podem excluir ou escrever uma nota.

  • Leitor do projeto, leitor do Firebase, visualizador de qualidade ou Leitor do Crashlytics

O que é um problema regredido?

A regressão acontece quando você encerra um problema, mas o Crashlytics recebe um relatório novo informando que ele ocorreu novamente. O Crashlytics reabre esses problemas automaticamente para que possam ser resolvidos da forma mais apropriada no seu app.

Veja um exemplo de como o Crashlytics classifica um problema como uma regressão:

1. O Crashlytics recebe um relatório de erros sobre a falha A pela primeira vez. O Crashlytics abre um problema correspondente para essa falha (problema A).
2. Você corrige esse bug, fecha o problema A e lança uma nova versão do seu app.
3. O Crashlytics recebe outro relatório sobre o problema A depois que ele foi encerrado.
   • O Crashlytics não vai considerar o problema como reaberto se o relatório for de uma versão do app que o Crashlytics conhecia no momento em que o problema foi encerrado (ou seja, a versão enviou um relatório de erro para todos os erros). O problema vai permanecer encerrado.
   • O Crashlytics considera o problema como reaberto se o relatório for de uma versão do app que o Crashlytics nãoconhecia no momento em que o problema foi encerrado (ou seja, a versão nunca enviou qualquer relatório de erro).

Quando um problema é regredido, enviamos um alerta de detecção de regressão e adicionamos um sinal ao problema para informar que o Crashlytics reabriu o problema. Se você não quiser que um problema seja reaberto devido ao nosso algoritmo de regressão, "ignore" o problema em vez de fechá-lo.

Por que estão aparecendo problemas regredidos de versões mais antigas do app?

O Crashlytics considera um problema como regredido se um relatório for de uma versão antiga do app que nunca enviou relatórios de erros no momento em que o problema foi encerrado.

Isso pode acontecer na seguinte situação: você corrigiu um bug e lançou uma nova versão do app, mas ainda há usuários em versões anteriores sem a correção de bug. Se uma dessas versões anteriores nunca tiver enviado relatórios de erros no momento em que o problema foi encerrado, e esses usuários começarem a descobrir o bug, esses relatórios de erros podem acionar um problema reaberto.

Se você não quiser que um problema seja reaberto devido ao nosso algoritmo de regressão, "ignore" o problema em vez de fechá-lo.

O app também usa o SDK do Google Mobile Ads, mas não está recebendo relatórios de falhas

Se o projeto usa Crashlytics com o SDK do Google Mobile Ads, é provável que as ferramentas de relatórios de falhas causem interferências ao registrar gerenciadores de exceções. Para corrigir o problema, desative a geração de relatórios de falhas no SDK do Mobile Ads chamando disableSDKCrashReporting.

Onde está meu conjunto de dados do BigQuery?

Depois de vincular o Crashlytics ao BigQuery, os conjuntos de dados que você criar serão automaticamente localizados nos Estados Unidos, independentemente do local do seu projeto do Firebase.

Os dSYMs estão ausentes ou não estão sendo enviados

Para fazer upload dos dSYMs do seu projeto e receber resultados detalhados, verifique o seguinte:

1. Verifique se a fase de build do seu projeto contém o script de execução do Crashlytics, que permite que o Xcode faça upload dos dSYMs do projeto no tempo de build. Acesse Como inicializar o Crashlytics para ver instruções sobre como adicionar o script. Depois de atualizar seu projeto, force uma falha e confirme se ela aparece no painel do Crashlytics.

2. Se o alerta dSYM ausente aparecer no console do Firebase verifique o Xcode para garantir que ele está produzindo dSYMs corretamente para o build.

3. Se o Xcode estiver produzindo dSYMs adequadamente e a mensagem de dSYMs ausentes continuar a aparecer, pode ser que a ferramenta de script de execução esteja bloqueada durante o upload dos dSYMs. Nesse caso, tente seguir estas etapas:

   • Verifique se você está usando a versão mais recente do Crashlytics.

   • Faça upload manual dos arquivos dSYM ausentes:

     • Opção 1: use a opção "Arrastar e soltar" baseada no console na guia dSYMs para fazer upload de um arquivo ZIP contendo os arquivos dSYM ausentes.
     • Opção 2: use o script upload-symbols para fazer upload dos arquivos dSYM ausentes nos UUIDs fornecidos nodSYMs guia.

4. Se você continuar vendo dSYMs ausentes ou se os uploads ainda não tiverem sido concluídos, entre em contato com o Suporte do Firebase e inclua seus registros.

Falhas mal simbolizadas

Caso os stack traces pareçam estar mal simbolizados, verifique os seguintes dados:

• Se os quadros da biblioteca do app não têm referências ao código do app, verifique se -fomit-frame-pointer não está definido como uma sinalização de compilação.

• Se vários frames (Missing) aparecerem para a biblioteca do seu app, veja se há dSYMs opcionais listados como ausentes (para a versão do app afetada) na guia dSYMs do Crashlytics do console do Firebase. Em caso afirmativo, siga a etapa da solução de problemas Alerta de dSYM ausente nas Perguntas frequentes sobre dSYMs ausentes ou sem upload nesta página. O upload desses dSYMs não simboliza falhas que já ocorreram, mas ajuda a garantir a simbolização de falhas futuras.

Posso usar o Crashlytics para macOS ou tvOS?

Sim, o Crashlytics pode ser implementado em projetos para macOS e tvOS. Inclua a v8.9.0 ou a versão mais recente do SDK do Firebase para Google Analytics para que as falhas tenham acesso às métricas coletadas pelo Google Analytics (usuários sem falhas, versão mais recente, alertas de velocidade e registros de navegação estrutural).

Posso usar o Crashlytics em um projeto do Firebase com vários apps em diferentes plataformas da Apple?

Agora você pode informar falhas de vários apps em um único projeto do Firebase, mesmo quando eles são criados para diferentes plataformas da Apple (por exemplo, iOS, tvOS e Mac Catalyst). Antes, você precisava separar os apps em projetos individuais do Firebase se eles tivessem o mesmo ID de pacote.

Por que os ANRs são informados apenas para o Android 11 e versões mais recentes?

O Crashlytics oferece suporte à geração de relatórios de ANR para apps Android em dispositivos que executam o Android 11 e versões mais recentes. A API usada para coletar ANRs (getHistoricalProcessExitReasons) é mais confiável do que as abordagens baseadas em SIGQUIT ou watchdog. Essa API está disponível apenas em dispositivos Android 11 ou com versões mais recentes.

Por que alguns ANRs não têm BuildIds?

Caso alguns ANRs estejam com BuildIds faltando, faça o seguinte para resolver problemas:

• Verifique se você está usando a versão mais recente do SDK do Android para Crashlytics e do plug-in do Gradle para Crashlytics.

  Caso não encontre BuildIds para o Android 11 e alguns ANRs do Android 12, é provável que você esteja usando um SDK e/ou um plug-in do Gradle desatualizado. Para coletar BuildIds corretamente para os ANRs, é preciso usar estas versões:

  • SDK do Android para Crashlytics v18.3.5+ (Firebase BoM v31.2.2+)
  • Plug-in do Gradle para Crashlytics v2.9.4+

• Verifique se você está usando um local não padrão para suas bibliotecas compartilhadas.

  Se os BuildIds só estiverem faltando nas bibliotecas compartilhadas do seu app, é provável que você não esteja usando o local padrão para elas. Se esse for o caso, talvez o Crashlytics não consiga localizar os BuildIds associados. Recomendamos que você use o local padrão para as bibliotecas compartilhadas.

• Verifique se você não está removendo BuildIds durante o processo de build.

  As dicas de solução de problemas a seguir se aplicam a ANRs e também a falhas nativas.

  • Verifique se os BuildIds estão executando readelf -n nos seus programas binários. Se os BuildIds estiverem faltando, adicione -Wl,--build-id às sinalizações do sistema de build.

  • Verifique se você não está removendo BuildIds acidentalmente para reduzir o tamanho do APK.

  • Se você mantiver as versões removidas e não removidas de uma biblioteca, não se esqueça de apontar a versão correta no código.

Diferenças entre os relatórios de ANR no painel do Crashlyticse no Google Play Console

Pode haver diferenças na contagem de ANRs do Google Play e do Crashlytics. Isso é esperado devido à diferença no mecanismo de geração de relatórios e coleta de dados de ANR. O Crashlytics registra ANRs na próxima inicialização do app, e o Android vitals envia os dados após a ocorrência dos ANRs.

Além disso, o Crashlytics só exibe ANRs que ocorrem em dispositivos com o Android 11 e versões mais recentes, e o Google Play exibe ANRs de dispositivos que têm o Google Play Services e o consentimento de coleta de dados aceito.

Por que vejo falhas em arquivos .kt marcadas como problemas .java?

Quando um app usa um ofuscador que não expõe a extensão do arquivo, o Crashlytics gera cada problema com uma extensão de arquivo .java por padrão.

Para que o Crashlytics possa gerar problemas com a extensão de arquivo correta, verifique se o app:

• usa o Android para Gradle 4.2.0 ou versões mais recentes
• usa o R8 com a ofuscação ativada. Para atualizar seu app para o R8, siga este documento.

Depois de fazer a atualização para a configuração descrita acima, é possível que novos problemas .kt que são cópias de problemas .java existentes apareçam. Consulte as Perguntas frequentes para saber mais sobre essa situação.

Por que aparecem problemas .kt que são cópias de problemas .java que já existem?

Em meados de dezembro de 2021, o Crashlytics melhorou o suporte para aplicativos que usam Kotlin.

Até pouco tempo, os ofuscadores disponíveis não mostravam a extensão do arquivo, por isso o Crashlytics gerava cada problema com uma extensão de arquivo .java por padrão. No entanto, a partir do Android para Gradle 4.2.0, o R8 passou a aceitar extensões de arquivos.

Com essa atualização, o Crashlytics pode determinar se cada classe usada no app foi escrita em Kotlin e incluir o nome de arquivo correto na assinatura do problema. Agora as falhas são atribuídas corretamente aos arquivos .kt (como apropriado) quando o app tem a seguinte configuração:

• O app usa o Android para Gradle 4.2.0 ou com versão mais recente.
• O app usa o R8 com a ofuscação ativada.

Como as novas falhas agora incluem a extensão de arquivo correta nas assinaturas dos problemas, podem aparecer novos problemas .kt que são apenas cópias dos problemas .java que já existem. No console do Firebase, tentamos identificar e informar você quando um novo problema .kt é uma possível cópia de um problema .java que já existe.

Não estou recebendo relatórios de falhas com o Dexguard

Se a exceção a seguir aparecer, você provavelmente está usando uma versão do DexGuard incompatível com o SDK do Firebase Crashlytics:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

Essa exceção não provoca uma falha no app, mas impede o envio de relatórios de erros. Para corrigir isso, faça o seguinte:

1. Verifique se você está usando a versão mais recente do DexGuard 8.x. Ela contém regras exigidas pelo SDK do Firebase Crashlytics.

2. Se você não quiser alterar sua versão do DexGuard, tente adicionar esta linha às regras de ofuscação no arquivo de configuração do DexGuard:

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

Diferenças entre os stack traces do NDK no painel do Crashlytics e no logcat

Os conjuntos de ferramentas LLVM e GNU têm padrões e tratamentos distintos para o segmento somente leitura dos binários do app, o que pode gerar stack traces inconsistentes no console do Firebase. Para atenuar isso, adicione as seguintes flags do vinculador ao seu processo de build:

• Se você estiver usando o vinculador lld do conjunto de ferramentas LLVM, adicione:

  -Wl,--no-rosegment

• Se você estiver usando o vinculador ld.gold do conjunto de ferramentas GNU, adicione:

  -Wl,--rosegment

Se você ainda estiver vendo inconsistências de stack trace (ou se nenhuma sinalização for relevante para seu conjunto de ferramentas), adicione o seguinte ao processo de compilação:

-fno-omit-frame-pointer

Como usar meu próprio binário para NDK gerador de arquivos de símbolo do Breakpad?

O plug-in do Crashlytics agrupa um gerador de arquivos de símbolo personalizados do Breakpad. Se você prefere usar seu próprio binário para gerar arquivos de símbolo do Breakpad (por exemplo, para criar os executáveis nativos da cadeia de builds direto da fonte), use a propriedade de extensão symbolGeneratorBinary opcional para especificar o caminho para o executável.

Há duas formas de especificar o caminho para o binário gerador de arquivos de símbolo do Breakpad:

• Opção 1: especificar o caminho usando a extensão firebaseCrashlytics no arquivo build.gradle

  Adicione o seguinte ao seu arquivo build.gradle.kts no nível do app:

  Plug-in para Gradle v3.0.0 ou mais recente

  android {
    buildTypes {
      release {
        configure<CrashlyticsExtension> {
          nativeSymbolUploadEnabled = true
          // Add these optional fields to specify the path to the executable
          symbolGeneratorType = "breakpad"
          breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
        }
      }
    }
  }

  versões anteriores do plug-in

  android {
    // ...
    buildTypes {
      // ...
      release {
        // ...
        firebaseCrashlytics {
          // existing; required for either symbol file generator
          nativeSymbolUploadEnabled true
          // Add this optional new block to specify the path to the executable
          symbolGenerator {
            breakpad {
              binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
     }
  }

• Opção 2: especificar o caminho usando uma linha de propriedade no arquivo do Gradle

  Você pode usar a propriedade com.google.firebase.crashlytics.breakpadBinary para especificar o caminho para o executável.

  É possível atualizar o arquivo de propriedades do Gradle manualmente ou atualizar o arquivo usando a linha de comando. Por exemplo, para especificar o caminho pela linha, use um comando como este:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

O Crashlytics oferece suporte ao armeabi?

O NDK do Firebase Crashlytics não funciona com ARMv5 (armeabi). A compatibilidade com essa ABI foi removida a partir do NDK r17.

Stack traces não simbolizados em apps Android estão aparecendo no painel do Crashlytics

Se você estiver usando o IL2CPP do Unity e encontrar stack traces não simbolizados, faça o seguinte:

1. Verifique se você está usando a versão 8.6.1 ou mais recente do SDK do Crashlytics para Unity.

2. Verifique se você configurou e está executando o comando crashlytics:symbols:upload da CLI do Firebase para gerar e fazer upload do arquivo de símbolo.

   Esse comando da CLI precisa ser executado sempre que você criar um build de lançamento ou qualquer build com stack traces que você queira ver simbolizados no console do Firebase. Saiba mais em Receber relatórios de erros legíveis.

O Crashlytics pode ser usado com apps que usam IL2CPP?

Sim, o Crashlytics pode exibir stack traces simbolizados para seus apps que usam IL2CPP. Esse recurso está disponível para apps lançados em plataformas Android ou Apple. Veja o que você precisa fazer:

1. Verifique se você está usando a versão 8.6.0 ou mais recente do SDK do Crashlytics para Unity.

2. Conclua as tarefas necessárias para sua plataforma:

   • Para apps da plataforma Apple: nenhuma ação especial é necessária. Para apps da plataforma Apple, o plug-in do Editor do Firebase para Unity configura automaticamente seu projeto do Xcode para fazer upload dos símbolos.

   • Para apps Android: verifique se você configurou e está executando o comando crashlytics:symbols:upload da CLI do Firebase para gerar e fazer upload do arquivo de símbolo.

     Esse comando da CLI precisa ser executado sempre que você criar um build de lançamento ou qualquer build com stack traces que você queira ver simbolizados no console do Firebase. Saiba mais em Receber relatórios de erros legíveis.

Por que um app deve informar exceções não capturadas como fatais?

Ao informar exceções não identificadas como fatais, você tem uma indicação mais realista de quais exceções podem resultar na impossibilidade de jogar o jogo, mesmo que o app continue em execução.

Se você começar a informar erros fatais, a porcentagem de usuários sem falhas (CFU, na sigla em inglês) provavelmente vai diminuir, mas a métrica de CFU será mais representativa das experiências dos usuários finais com seu app.

Quais exceções serão reportadas como fatais?

Para que o Crashlytics informe uma exceção não identificada como fatal, as duas condições a seguir precisam ser atendidas:

• Durante a inicialização do app, a propriedade ReportUncaughtExceptionsAsFatal precisa ser definida como true.

• Seu app (ou uma biblioteca incluída) gera uma exceção que não é capturada. Uma exceção que é criada, mas não lançada, não é considerada não capturada.

Depois de ativar os relatórios de exceções não capturadas como fatais, agora tenho muitos novos erros fatais. Como lidar corretamente com essas exceções?

Quando você começar a receber relatórios de exceções não capturadas como fatais, confira algumas opções para processar essas exceções:

• Pense em como começar a capturar e processar as exceções não capturadas.
• Considere opções diferentes para registrar exceções no console de depuração do Unity e no Crashlytics.

Detectar e processar exceções geradas

Exceções são criadas e geradas para refletir estados inesperados ou excepcionais. Resolver os problemas refletidos por uma exceção gerada envolve retornar o programa a um estado conhecido (processo conhecido como processamento de exceções).

A prática recomendada é capturar e processar todas as exceções previstas, a menos que o programa não possa retornar a um estado conhecido.

Para controlar quais tipos de exceções são capturadas e processadas por código, una o código que pode gerar uma exceção em um bloco try-catch. Verifique se as condições nas instruções catch são as mais restritas possíveis para processar as exceções específicas de maneira adequada.

Registrar exceções no Unity ou no Crashlytics

Há várias formas de registrar exceções no Unity ou no Crashlytics para ajudar a depurar o problema.

Ao usar o Crashlytics, confira as duas opções mais comuns e recomendadas:

• Opção 1: mostrar no console do Unity, mas não informar ao Crashlytics durante o desenvolvimento ou a solução de problemas

  • Mostre no console do Unity usando Debug.Log(exception), Debug.LogWarning(exception) e Debug.LogError(exception), que mostram o conteúdo da exceção e não geram a exceção outra vez.

• Opção 2: fazer upload para o Crashlytics para gerar relatórios consolidados no painel do Crashlytics nestas situações:

  • Se vale a pena registrar uma exceção para depurar um possível evento do Crashlytics subsequente, use Crashlytics.Log(exception.ToString()).
  • Caso uma exceção ainda precise ser informada ao Crashlytics mesmo que tenha sido capturada e processada, use Crashlytics.LogException(exception) para registrá-la como um evento não fatal.

No entanto, se você quiser relatar manualmente um evento fatal para o Cloud Diagnostics do Unity, use Debug.LogException. Essa opção exibe a exceção no console do Unity, como a opção 1, mas também gera a exceção, mesmo que ela ainda não tenha sido gerada ou capturada. Ele gera o erro de modo não local. Isso significa que mesmo um Debug.LogException(exception) circundante com blocos try-catch ainda resulta em uma exceção não capturada.

Portanto, chame Debug.LogException apenas se você quiser fazer todas as ações a seguir:

• Mostrar a exceção no console do Unity.
• Fazer upload da exceção para o Crashlytics como um evento fatal.
• Para gerar a exceção, trate-a como uma exceção não capturada e faça com que ela seja informada ao Cloud Diagnostics do Unity.

Para mostrar uma exceção capturada no console do Unity e fazer upload para o Crashlytics como um evento não fatal, faça o seguinte:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}