Esta página fornece ajuda para solução de problemas e respostas para perguntas frequentes sobre o uso do Crashlytics. Se você não encontrar o que está procurando ou precisar de ajuda adicional, entre em contato com o suporte do Firebase .
Solução geral de problemas/FAQ
Se você não estiver vendo usuários sem falhas, registros de navegação e/ou alertas de velocidade, recomendamos verificar a configuração do seu aplicativo para o Google Analytics.
Verifique se você ativou o Google Analytics em seu projeto Firebase.
Certifique-se de que o compartilhamento de dados esteja ativado para o Google Analytics na página Integrações > Google Analytics do console do Firebase. Observe que as configurações de compartilhamento de dados são exibidas no console do Firebase, mas gerenciadas no console do Google Analytics.
Além do Firebase Crashlytics SDK, certifique-se de ter adicionado o Firebase SDK para Google Analytics ao seu aplicativo ( iOS+ | Android ).
Certifique-se de usar as versões mais recentes para todos os SDKs do Firebase ( iOS+ | Android ).
Verifique especialmente se você está usando no mínimo as seguintes versões do Firebase SDK para Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ para macOS e tvOS) | Android — v17.2.3+(BoM v24.7.1+) .
Você pode observar dois formatos diferentes para os problemas listados na tabela Problemas no console do Firebase. Aqui está o porquê!
O Crashlytics analisa todos os eventos do seu aplicativo — travamentos, não fatais e ANRs — e agrupa eventos 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 seu aplicativo e um design atualizado para exibir novos problemas.
Aqui está o que você experimentará com essas melhorias:
Metadados renovados exibidos na linha do problema
Agora ficou mais fácil entender e fazer a triagem de problemas em seu aplicativo.Menos problemas duplicados
Uma alteração de número de linha não resulta em um novo problema.Alertas e sinais mais significativos
Um novo problema, na verdade, representa um novo bug.Pesquisa mais poderosa
Cada problema contém mais metadados pesquisáveis, como tipo de exceção e nome do pacote.
Veja como essas melhorias estão sendo lançadas:
Quando recebermos novos eventos do seu aplicativo, verificaremos se eles correspondem a um problema existente.
Se não houver correspondência, aplicaremos automaticamente nosso algoritmo de agrupamento de eventos mais inteligente ao evento e criaremos um novo problema com o design de metadados renovado.
Esta é a primeira grande atualização que estamos fazendo em nosso agrupamento de eventos. Se você tiver comentários ou encontrar algum problema, informe-nos preenchendo um relatório.
O valor sem falhas representa a porcentagem de usuários que interagiram com seu aplicativo, mas não tiveram falhas em um período específico.
Aqui está a fórmula para calcular a porcentagem de usuários sem falhas. Seus 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_exceptione 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 aplicativo 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 ao longo do tempo , não uma média.
Por exemplo, imagine que seu aplicativo tenha três usuários; vamos chamá-los de Usuário A, Usuário B e Usuário C. A tabela a seguir mostra quais usuários interagiram com seu aplicativo todos os dias e quais desses usuários tiveram uma falha naquele dia:
| Segunda-feira | Terça-feira | Quarta-feira | |
|---|---|---|---|
| Usuários que interagiram com seu aplicativo | A,B,C | A,B,C | A,B |
| Usuário que teve uma falha | C | B | UMA |
Na quarta-feira, sua porcentagem de usuários sem falhas é de 50% (1 em cada 2 usuários estava sem falhas).
Dois de seus usuários interagiram com seu aplicativo na quarta-feira, mas apenas um deles (usuário B) não apresentou falhas.Nos últimos 2 dias, sua porcentagem de usuários sem falhas foi de 33,3% (1 em cada 3 usuários não apresentou falhas).
Três de seus usuários interagiram com seu aplicativo nos últimos dois dias, mas apenas um deles (usuário C) não apresentou falhas.Nos últimos 3 dias, sua porcentagem de usuários sem falhas foi de 0% (0 em 3 usuários não apresentou falhas).
Três de seus usuários interagiram com seu aplicativo nos últimos três dias, mas nenhum deles não teve falhas.
As notas permitem que os membros do projeto comentem sobre problemas específicos com perguntas, atualizações de status, etc.
Quando um membro do projeto publica uma nota, ela é marcada com o e-mail de sua conta do Google. Esse endereço de e-mail fica visível, junto com a nota, para todos os membros do projeto com acesso para visualizar a nota.
O seguinte descreve o acesso necessário para visualizar, escrever e excluir notas:
Os membros do projeto com qualquer uma das funções a seguir podem visualizar e excluir notas existentes e 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 uma das funções a seguir podem visualizar as notas postadas sobre um problema, mas não podem excluir ou escrever uma nota.
- Visualizador de projeto, visualizador Firebase, visualizador de qualidade ou visualizador de Crashlytics
Integrações
Se o seu projeto usa o Crashlytics juntamente com o SDK de anúncios para celular do Google, é provável que os relatórios de falhas estejam interferindo ao registrar manipuladores de exceção. Para corrigir o problema, desative o relatório de falhas no Mobile Ads SDK chamando disableSDKCrashReporting .
Depois de vincular o Crashlytics ao BigQuery, os novos conjuntos de dados que você criar serão automaticamente localizados nos Estados Unidos, independentemente da localização do seu projeto do Firebase.
Suporte de plataforma
Problemas regredidos
Um problema teve uma regressão quando você o fechou anteriormente, mas o Crashlytics recebe um novo relatório informando que o problema ocorreu novamente. O Crashlytics reabre automaticamente esses problemas regredidos para que você possa resolvê-los conforme apropriado para seu aplicativo.
Veja um cenário de exemplo que explica como o Crashlytics categoriza um problema como uma regressão:
- Pela primeira vez, o Crashlytics obtém um relatório de falha sobre o Crash "A". O Crashlytics abre um problema correspondente para essa falha (Problema "A").
- Você corrige esse bug rapidamente, fecha o problema "A" e lança uma nova versão do seu aplicativo.
- O Crashlytics recebe outro relatório sobre o problema "A" depois que você fecha o problema.
- Se o relatório for de uma versão do aplicativo que o Crashlytics sabia quando você fechou o problema (o que significa que a versão enviou um relatório de falha para qualquer falha), o Crashlytics não considerará o problema como regredido. A questão permanecerá encerrada.
- Se o relatório for de uma versão do aplicativo que o Crashlytics não conhecia quando você fechou o problema (o que significa que a versão nunca enviou nenhum relatório de falha para nenhuma falha), o Crashlytics considera o problema regredido e reabrirá o problema .
Quando um problema regride, enviamos um alerta de detecção de regressão e adicionamos um sinal de regressão 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, "silencie" o problema em vez de fechá-lo.
Se um relatório for de uma versão antiga do aplicativo que nunca enviou nenhum relatório de falha quando você fechou o problema, o Crashlytics considera o problema regredido e reabrirá o problema.
Essa situação pode acontecer na seguinte situação: Você corrigiu um bug e lançou uma nova versão do seu aplicativo, mas ainda tem usuários em versões mais antigas sem a correção do bug. Se, por acaso, uma dessas versões mais antigas nunca tivesse enviado nenhum relatório de travamento quando você fechou o problema e esses usuários começassem a encontrar o bug, esses relatórios de travamento acionariam um problema regredido.
Se você não quiser que um problema seja reaberto devido ao nosso algoritmo de regressão, "silencie" o problema em vez de fechá-lo.