Solução de problemas e perguntas frequentes sobre o Crashlytics
Nesta página, você vai encontrar respostas para perguntas frequentes
sobre como usar o Crashlytics e ajuda para solucionar problemas. Caso
não encontre o que procura ou precise de ajuda, entre em contato com o
suporte do Firebase.
Solução de problemas gerais/perguntas frequentes
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á
métricas sem falhas e/ou alertas de velocidade
Caso nenhuma métrica sem falha (como usuários e sessões sem falhas)
e/ou alerta de velocidade seja exibido, veja se você está usando o
SDK do Crashlytics v10.8.0+.
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:
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).
Os dSYMs estão ausentes ou não estão sendo enviados
Para fazer upload dos dSYMs do seu projeto e receber resultados detalhados, verifique o seguinte:
Verifique se a fase de build do seu projeto contém o script de execução do Crashlytics,
que permite que o Xcode faça upload dos dSYMs do projeto no tempo de build. Acesse
Como inicializar o Crashlytics
para ver instruções sobre como adicionar o script. Depois de atualizar seu projeto,
force uma falha e confirme se ela
aparece no painel do Crashlytics.
Se o alerta dSYM ausente aparecer no console do Firebase verifique o Xcode para
garantir que ele está produzindo dSYMs corretamente
para o build.
Se o Xcode estiver produzindo dSYMs adequadamente e a mensagem de dSYMs ausentes continuar a aparecer,
pode ser que a ferramenta de script de execução esteja bloqueada durante o upload dos dSYMs.
Nesse caso, tente seguir estas etapas:
Verifique se você está usando a versão mais recente do Crashlytics.
Faça upload manual dos arquivos dSYM ausentes:
Opção 1: use a opção "Arrastar e soltar" baseada no console na
guia dSYMs
para fazer upload de um arquivo ZIP contendo os arquivos dSYM ausentes.
Opção 2: use o
script upload-symbols
para fazer upload dos arquivos dSYM ausentes nos UUIDs fornecidos nodSYMs
guia.
Se você continuar vendo dSYMs ausentes ou se os uploads ainda não tiverem sido concluídos, entre em contato com o Suporte do Firebase e inclua seus registros.
Falhas mal
simbolizadas
Caso os stack traces pareçam estar mal simbolizados, verifique os seguintes dados:
Se os frames da biblioteca do seu app não têm referências ao código do app, veja
se -fomit-frame-pointer não está definido como uma
flag de compilação.
Se vários frames (Missing) aparecerem para a biblioteca do seu app, veja se há
dSYMs opcionais listados como ausentes (para a versão do app afetada) na
guia dSYMs do Crashlytics
do console do Firebase. Em caso afirmativo, siga a etapa da solução de problemas
Alerta de dSYM ausente nas
Perguntas frequentes sobre dSYMs ausentes ou sem upload
nesta página. O upload desses dSYMs não simboliza falhas
que já ocorreram, mas ajuda a garantir a simbolização de
falhas futuras.
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.
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.
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.
Suporte a plataformas
Posso usar o Crashlytics para macOS ou tvOS?
Sim, o Crashlytics pode ser implementado em projetos para macOS e tvOS. Inclua
a v8.9.0 ou a versão mais recente do SDK do Firebase para Google Analytics para que as falhas
tenham acesso às métricas coletadas pelo Google Analytics (usuários sem falhas,
versão mais recente, alertas de velocidade e registros de navegação estrutural).
Posso usar o Crashlytics em um projeto do Firebase com vários apps em diferentes plataformas da Apple?
Agora você pode informar falhas de vários apps em um único projeto do Firebase,
mesmo quando eles são criados para diferentes plataformas da Apple (por exemplo, iOS, tvOS e
Mac Catalyst). Antes, você precisava separar os apps em projetos individuais
do Firebase se eles tivessem o mesmo ID de pacote.
Problemas reabertos
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:
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).
Você corrige esse bug, fecha o problema A e lança uma nova versão do
seu app.
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 Crashlyticsconhecia 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 Crashlyticsnã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.
