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
Você pode notar dois formatos diferentes para problemas listados na tabela Problemas no console do Firebase. E você também pode notar um recurso chamado “variantes” em alguns de seus problemas. Aqui está o porquê!
No início de 2023, lançamos um mecanismo de análise aprimorado para agrupar eventos, bem como um design atualizado e alguns recursos avançados para novos problemas (como variantes!). Confira nossa postagem recente no blog para todos os detalhes, mas você pode ler abaixo os destaques.
O Crashlytics analisa todos os eventos do seu aplicativo (como falhas, não fatais e ANRs) e cria grupos de eventos chamados de problemas – todos os eventos em um problema têm um ponto comum de falha.
Para agrupar eventos nesses problemas, o mecanismo de análise aprimorado agora analisa muitos aspectos do evento, incluindo os quadros no rastreamento de pilha, a mensagem de exceção, o código de erro e outras características de plataforma ou de tipo de erro.
No entanto, dentro deste grupo de eventos, os rastreamentos de pilha que levam à falha podem ser diferentes. Um rastreamento de pilha diferente pode significar uma causa raiz diferente. Para representar essa possível diferença dentro de um problema, agora criamos variantes dentro de problemas - cada variante é um subgrupo de eventos em um problema que tem o mesmo ponto de falha e um rastreamento de pilha semelhante. Com variantes, você pode depurar os rastreamentos de pilha mais comuns em um problema e determinar se diferentes causas raiz estão levando à falha.
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 no seu aplicativo.Menos problemas duplicados
Uma alteração no número de linha não resulta em um novo problema.Depuração mais fácil de problemas complexos com diversas causas raiz
Use variantes para depurar os rastreamentos de pilha mais comuns em um problema.Alertas e sinais mais significativos
Um novo problema, na verdade, representa um novo bug.Pesquisa mais poderosa
Cada edição contém mais metadados pesquisáveis, como tipo de exceção e nome do pacote.
Veja como essas melhorias estão sendo implementadas:
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.
Se você não estiver vendo métricas sem falhas (como usuários e sessões sem falhas) e/ou alertas de velocidade, certifique-se de estar usando oSDK do Crashlytics 11.7.0+.
Se você não estiver vendo os registros de localização atual , recomendamos verificar a configuração do seu aplicativo para o Google Analytics. Certifique-se de atender aos seguintes requisitos:
Você ativou o Google Analytics em seu projeto do Firebase.
Você ativou o compartilhamento de dados para o Google Analytics. Saiba mais sobre essa configuração em Gerenciar suas configurações de compartilhamento de dados do Analytics
Vocêadicionou o SDK do Firebase para Google Analyticsao seu aplicativo. Este SDK deve ser adicionado além do SDK do Crashlytics.
Você está usando as versões mais recentes do SDK do Firebase l10nversões mais recentes do SDK do Firebasepara todos os produtos que você usa no seu aplicativo.
Se você estiver usando o Unity IL2CPP e estiver vendo rastreamentos de pilha não simbolizados, tente o seguinte:
Certifique-se de estar usando a versão 8.6.1 ou superior do SDK do Crashlytics Unity.
Verifique se você está configurado e executando o comando
crashlytics:symbols:uploadCLI do Firebase para gerar e fazer upload do arquivo de símbolo.Você precisa executar este comando CLI sempre que criar uma versão ou qualquer compilação para a qual deseja ver rastreamentos de pilha simbolizados no console do Firebase. Saiba mais na página Obter relatórios de falhas legíveis .
Sim, o Crashlytics pode exibir stack traces simbolizados para seus aplicativos que usam IL2CPP. Esse recurso está disponível para aplicativos lançados nas plataformas Android ou Apple. Aqui está o que você precisa fazer:
Certifique-se de estar usando a versão 8.6.0 ou superior do SDK do Crashlytics Unity.
Conclua as tarefas necessárias para sua plataforma:
Para aplicativos da plataforma Apple : nenhuma ação especial é necessária. Para aplicativos da plataforma Apple, o plug-in Firebase Unity Editor configura automaticamente seu projeto Xcode para fazer upload de símbolos.
Para aplicativos Android : verifique se você está configurado e executando o comando
crashlytics:symbols:uploadCLI do Firebase para gerar e fazer upload do arquivo de símbolo.Você precisa executar este comando CLI sempre que criar uma versão ou qualquer compilação para a qual deseja ver rastreamentos de pilha simbolizados no console do Firebase. Saiba mais na página Obter relatórios de falhas legíveis .
O valor sem falhas representa a porcentagem de usuários que interagiram com seu aplicativo, mas não tiveram falhas durante 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 e 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 | A |
Na quarta-feira, a porcentagem de usuários sem falhas é de 50% (1 em cada 2 usuários não teve 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, a porcentagem de usuários sem falhas foi de 33,3% (1 em cada 3 usuários não teve falhas).
Três dos seus usuários interagiram com seu aplicativo nos últimos dois dias, mas apenas um deles (usuário C) não teve falhas.Nos últimos 3 dias, a porcentagem de usuários sem falhas foi 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 teve nenhuma falha.
O valor de usuários sem falhas não deve ser comparado em períodos diferentes. A probabilidade de um único usuário sofrer uma falha aumenta quanto mais vezes ele usa seu aplicativo, portanto, o valor dos usuários sem falhas provavelmente será menor por períodos mais longos.
As notas permitem que os membros do projeto comentem sobre questões específicas com perguntas, atualizações de status, etc.
Quando um membro do projeto posta uma nota, ela é marcada com o e-mail da conta do Google dele. Este 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.
Os membros do projeto com qualquer uma das funções a seguir podem visualizar as notas publicadas sobre um problema, mas não podem excluir ou escrever uma nota.
Consulte Compreender métricas sem falhas .
As notas permitem que os membros do projeto comentem sobre questões específicas com perguntas, atualizações de status, etc.
Quando um membro do projeto posta uma nota, ela é marcada com o e-mail da conta do Google dele. Este 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.
Os membros do projeto com qualquer uma das funções a seguir podem visualizar as notas publicadas sobre um problema, mas não podem excluir ou escrever uma nota.
Integrações
Se seu projeto usa o Crashlytics junto com o SDK dos anúncios para dispositivos móveis do Google, é provável que os relatores de falhas estejam interferindo no registro dos manipuladores de exceções. 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 serão automaticamente localizados nos Estados Unidos, independentemente da localização do seu projeto do Firebase.
Problemas regredidos
Um problema regrediu 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 exemplo de cenário 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 obtém outro relatório sobre o problema "A" depois de você resolvê-lo.
- Se o relatório for de uma versão do aplicativo que o Crashlytics conhecia quando você resolveu 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. O assunto permanecerá encerrado.
- Se o relatório for de uma versão do aplicativo que o Crashlytics não conhecia quando você resolveu o problema (o que significa que a versão nunca enviou nenhum relatório de falha), o Crashlytics considerará 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, "silenciar" 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 considerará o problema regredido 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 tivesse enviado nenhum relatório de falha quando você resolveu o problema, e esses usuários começassem a encontrar o bug, então esses relatórios de falha desencadeariam um problema regredido.
Se você não quiser que um problema seja reaberto devido ao nosso algoritmo de regressão, "silenciar" o problema em vez de fechá-lo.
Relatando exceções não detectadas como fatais
O Crashlytics pode relatar exceções não detectadas como fatais (a partir da versão 10.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 relatar exceções não detectadas como fatais, você obtém uma indicação mais realista de quais exceções podem resultar na impossibilidade de jogar do jogo – mesmo que o aplicativo continue em execução.
Observe que se você começar a relatar mortes, a porcentagem de usuários sem falhas (CFU) provavelmente diminuirá, mas a métrica de CFU será mais representativa das experiências dos usuários finais com seu aplicativo.
Para que o Crashlytics relate uma exceção não detectada como fatal, ambas as condições a seguir devem ser atendidas:
Durante a inicialização do seu aplicativo, a propriedade
ReportUncaughtExceptionsAsFataldeve ser definida comotrue.Seu aplicativo (ou uma biblioteca incluída) gera uma exceção que não é detectada. Uma exceção criada, mas não lançada , não é considerada não capturada.
Quando você começa a receber relatórios de suas exceções não detectadas como fatais, aqui estão algumas opções para lidar com essas exceções não detectadas:
- Considere como você pode começar a capturar e lidar com essas exceções não detectadas.
- Considere diferentes opções para registrar exceções no console de depuração do Unity e no Crashlytics.
Capturar e tratar exceções lançadas
Exceções são criadas e lançadas para refletir estados inesperados ou excepcionais . Resolver os problemas refletidos por uma exceção lançada envolve retornar o programa a um estado conhecido (um processo conhecido como tratamento de exceções ).
É uma prática recomendada capturar e tratar 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 tratadas por qual código, envolva o código que pode gerar uma exceção em um bloco try-catch . Certifique-se de que as condições nas instruções catch sejam tão restritas quanto possível para lidar adequadamente com as exceções específicas.
Registrar exceções no Unity ou no Crashlytics
Existem várias maneiras de registrar exceções no Unity ou no Crashlytics para ajudar a depurar o problema.
Ao usar o Crashlytics, aqui estão as duas opções mais comuns e recomendadas:
Opção 1: Imprimir no console Unity, mas não reportar ao Crashlytics, durante o desenvolvimento ou solução de problemas
- Imprima no console do Unity usando
Debug.Log(exception),Debug.LogWarning(exception)eDebug.LogError(exception)que imprimem o conteúdo da exceção no console do Unity e não lançam novamente a exceção.
- Imprima no console do Unity usando
Opção 2: faça upload para o Crashlytics para obter relatórios consolidados no painel do Crashlytics nas seguintes situações:
- Se vale a pena registrar uma exceção para depurar um possível evento subsequente do Crashlytics, use
Crashlytics.Log(exception.ToString()). - Se uma exceção ainda precisar ser relatada ao Crashlytics apesar de ter sido capturada e tratada, use
Crashlytics.LogException(exception)para registrá-la como um evento não fatal.
- Se vale a pena registrar uma exceção para depurar um possível evento subsequente do Crashlytics, use
No entanto, se quiser relatar manualmente um evento fatal ao Unity Cloud Diagnostics, você poderá usar Debug.LogException . Esta opção imprime a exceção no console do Unity como a Opção 1, mas também lança a exceção (independentemente de ela ter sido lançada ou capturada ainda). Ele lança o erro de forma não local. Isso significa que mesmo um Debug.LogException(exception) circundante com blocos try-catch ainda resulta em uma exceção não detectada.
Portanto, chame Debug.LogException se e somente se você quiser fazer o seguinte :
- Para imprimir a exceção no console do Unity.
- Para fazer upload da exceção para o Crashlytics como um evento fatal.
- Para lançar a exceção, trate-a como uma exceção não detectada e relate-a ao Unity Cloud Diagnostics.
Observe que se você quiser imprimir uma exceção capturada no console do Unity e carregá-la no 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
//
}