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

Não vejo usuários sem falhas, registros de navegação estrutural e/ou alertas de velocidade

Caso não encontre usuários sem falhas, registros de navegação estrutural e/ou alertas de velocidade, verifique a configuração do seu aplicativo para o Google Analytics.

• Verifique se você ativou o Google Analytics no seu projeto do Firebase.

• Verifique se o compartilhamento de dados está ativado para o Google Analytics na página Integrações > Google Analytics do Console do Firebase. As configurações de compartilhamento de dados são exibidas no Console do Firebase, mas são gerenciadas no console do Google Analytics.

• Além do SDK do Firebase Crashlytics, verifique se você adicionou o SDK do Firebase para o Google Analytics ao seu app (iOS+ | Android).

• Verifique se você está usando as versões mais recentes de todos os SDKs do Firebase (iOS+ | 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+).

Visualização de dois formatos diferentes na tabela Problemas

Talvez você veja dois formatos diferentes para os problemas listados na tabela Problemas no Console do Firebase. Confira abaixo por que isso acontece.

O Crashlytics analisa todos os eventos do app (falhas, erros não fatais e ANRs) para agrupar os casos semelhantes em problemas separados. Em janeiro de 2023, lançamos um mecanismo de análise aprimorado para agrupar eventos com base no código do app e também lançamos um design atualizado para mostrar novos problemas.

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.

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

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

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 pelo 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:

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

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 dos anúncios para dispositivos móveis do Google, mas não está recebendo relatórios de falhas.

Se o projeto usa o Crashlytics e o SDK dos anúncios para dispositivos móveis do Google, então as ferramentas de relatórios de falhas provavelmente estão interferindo durante o registro de gerenciadores de exceções. Para corrigir o problema, desative a geração de relatórios de falhas nesse SDK. Para fazer isso, chame disableSDKCrashReporting.

Onde está meu conjunto de dados do BigQuery?

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

O que é um problema reaberto?

Esses problemas ocorrem quando um problema que já foi encerrado tem uma ocorrência relatada novamente no Crashlytics. A ferramenta reabre esses problemas automaticamente para que eles possam ser resolvidos da maneira 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. Ele 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 a ferramenta 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 a ferramenta não conhecia no momento em que o problema foi encerrado (ou seja, a versão nunca enviou qualquer relatório de erro).

Quando um problema é reaberto, 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 estou vendo problemas reabertos de versões mais antigas do app?

O Crashlytics considera um problema como reaberto 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 do 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.