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

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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

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:

• 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ê ao seu app. O SDK precisa ser adicionado junto ao SDK do Crashlytics.

• Você está usando as para todos os produtos que você usa no seu app.

Não há alertas de velocidade

Se você não estiver recebendo alertas de velocidade, verifique se está usando o

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

• 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 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.

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 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.