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


Nesta página, você vai encontrar respostas para perguntas frequentes sobre como usar o Crashlytics e ajuda para solucionar problemas. Caso não encontre o que procura ou precise de ajuda, entre em contato com o suporte do Firebase.

Solução de problemas gerais/perguntas frequentes

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.

Caso nenhuma métrica sem falha (como usuários e sessões sem falhas) e/ou alerta de velocidade seja exibido, veja se você está usando o SDK do Crashlytics 11.7.0+.

Caso nenhum registro de navegação estrutural apareça, veja a configuração do Google Analytics no seu app. Verifique se você atende aos seguintes requisitos:

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 na página Receber relatórios de erros legíveis.

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 na página Receber relatórios de erros legíveis.

O valor sem falhas representa a porcentagem de usuários que interagiram com o app, mas que não tiveram falhas em um período específico.

Esta é a fórmula para calcular a porcentagem de usuários sem falhas. Os valores de entrada são fornecidos por Google Analytics.

CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100

  • Quando ocorre uma falha, o Google Analytics envia um tipo de evento app_exception, e CRASHED_USERS representa o número de usuários associados a esse tipo de evento.

  • ALL_USERS representa o número total de usuários que interagiram com seu app durante o período selecionado no menu suspenso no canto superior direito do painel do Crashlytics.

A porcentagem de usuários sem falhas é uma agregação feita ao longo do tempo, não uma média.

Por exemplo, imagine que seu app tem três usuários: Usuário A, Usuário B e Usuário C. A tabela a seguir mostra quais deles interagiram com seu app em cada dia e quais tiveram uma falha:

Segunda-feira Terça-feira Quarta-feira
Usuários que interagiram com seu app A, B, C A, B, C A, B
Usuário que teve uma falha C B A

  • Na quarta-feira, sua porcentagem de usuários sem falhas foi de 50%, sendo que um de dois usuários não teve uma falha.
    Dois usuários interagiram com o app na quarta-feira, mas apenas um deles (Usuário B) não teve falhas.

  • Nos últimos dois dias, sua porcentagem de usuários sem falhas foi de 33,3%, ou seja, um de três usuários não apresentou falhas.
    Três dos seus usuários interagiram com o app nos últimos dois dias, mas apenas um deles (Usuário C) não teve falhas.

  • Nos últimos três dias, a porcentagem de usuários sem falhas foi de 0%, ou seja, todos os usuários tiveram falhas.
    Três dos seus usuários interagiram com o app nos últimos três dias, e todos tiveram falhas.

O valor de usuários sem falhas não deve ser comparado entre períodos diferentes. A probabilidade de um único usuário enfrentar uma falha aumenta à medida que ele usa o app. Portanto, o valor de usuários sem falhas provavelmente será menor por períodos mais longos.

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:

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

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:

Integrações

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.

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.

Problemas reabertos

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.

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 mais antigas sem a correção de bug. Se uma dessas versões mais antigas 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.

Como informar exceções não capturadas como fatais

O Crashlytics pode relatar exceções não capturadas como fatais (a partir da v10.4.0 do SDK do Unity). As perguntas frequentes a seguir ajudam a explicar a lógica e as práticas recomendadas para usar esse recurso.

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.

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

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:

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