Esta página fornece ajuda para solução de problemas e respostas a perguntas frequentes sobre o uso do Crashlytics. Se você não encontrar o que procura ou precisar de ajuda adicional, entre em contato com o suporte do Firebase .
Solução de problemas gerais/FAQ
Se você não estiver vendo usuários sem falhas, logs 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 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. 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 SDK do Firebase Crashlytics, verifique se você adicionou o SDK do Firebase para Google Analytics ao seu aplicativo ( iOS+ | Android ).
Verifique se você está usando as versões mais recentes para todos os seus SDKs do Firebase ( iOS+ | Android ).
Verifique especialmente se você está usando no mínimo 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+) .
O valor sem falhas representa a porcentagem de usuários que interagiram com seu aplicativo, mas não tiveram uma falha 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 a cada dia 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 teve falhas.Nos últimos 2 dias, sua porcentagem de usuários sem falhas é de 33,3% (1 em cada 3 usuários estava sem 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 é de 0% (0 em cada 3 usuários não tiveram falhas).
Três dos seus usuários interagiram com seu aplicativo nos últimos três dias, mas nenhum deles não apresentou falhas.
As notas permitem que os membros do projeto comentem questões específicas com perguntas, atualizações de status, etc.
Quando um membro do projeto publica uma nota, ela é identificada com o e-mail de sua Conta do Google. Este endereço de e-mail é visível, juntamente 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 seguintes funções 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 seguintes funções podem visualizar as notas publicadas em um problema, mas não podem excluir ou escrever uma nota.
- Visualizador de projeto , visualizador do Firebase , visualizador de qualidade ou visualizador do Crashlytics
Integrações
Se seu projeto usa o Crashlytics junto com o SDK de anúncios para dispositivos móveis do Google, é provável que os relatores de falhas estejam interferindo ao registrar manipuladores de exceção. Para corrigir o problema, desative os relatórios de falhas no SDK de anúncios para dispositivos móveis chamando disableSDKCrashReporting .
Depois de vincular o Crashlytics ao BigQuery, os novos conjuntos de dados criados são localizados automaticamente nos Estados Unidos, independentemente da localização do seu projeto do Firebase.
Suporte da plataforma
Problemas regredidos
Um problema teve uma regressão quando você o encerrou 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.
Aqui está um cenário de exemplo que explica como o Crashlytics categoriza um problema como uma regressão:
- Pela primeira vez, o Crashlytics recebe 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ê encerrou o problema.
- Se o relatório for de uma versão do aplicativo que o Crashlytics conhecia quando você encerrou 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ê encerrou o problema (o que significa que a versão nunca enviou nenhum relatório de falha para nenhuma falha), o Crashlytics considerará o problema regrediu 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ê encerrou o problema, o Crashlytics considerará o problema regrediu e o reabrirá.
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 tiver enviado nenhum relatório de falha quando você encerrou o problema, e esses usuários começarem a encontrar o bug, esses relatórios de falha acionariam um problema de regressão.
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.