Solução de problemas e perguntas frequentes sobre o Crashlytics
Nesta página, você encontrará respostas de perguntas frequentes
sobre como usar o Crashlytics e ajuda para solucionar problemas. Caso você
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
Há formatos diferentes (às vezes, "variantes") para alguns problemas na tabela Problemas
Talvez você veja dois formatos diferentes para os problemas listados na tabela Problemas
no Console do Firebase. Você também pode encontrar 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 verifique 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 agora analisa muitos aspectos do evento, incluindo os frames no stack trace, a mensagem de exceção, o código de 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 vejo
métricas sem falhas e/ou alertas de velocidade
Se você não estiver vendo métricas sem falhas (como usuários e sessões sem falhas)
e/ou alertas de velocidade, verifique se está usando o
SDK do Crashlytics v18.6.0 ou mais recente (ou BoM do Firebase v32.6.0 ou mais recente).
Não vejo os registros de navegação estrutural
Se você não estiver vendo
registros de navegação estrutural,
verifique 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: Android — v17.2.3+(BoM v24.7.1+).
Por que os ANRs são informados
apenas para o Android 11 e versões mais recentes?
O Crashlytics tem suporte a relatórios de ANR para apps Android em dispositivos com o
Android 11 e versões mais recentes. A API que usamos para coletar ANRs
(getHistoricalProcessExitReasons)
é mais confiável do que as abordagens baseadas em SIGQUIT ou watchdog. Essa API está
disponível apenas em dispositivos Android 11 ou com versões mais recentes.
Por que alguns ANRs não têm
BuildIds?
Se alguns ANRs não tiverem BuildIds, faça o seguinte:
Verifique se você está usando a versão mais recente do SDK do Crashlytics para Android e
do plug-in do Gradle para Crashlytics.
Se não encontrar BuildIds para o Android 11 e alguns ANRs do Android 12,
você provavelmente está usando um SDK e/ou um plug-in do Gradle desatualizado.
Para coletar BuildIds corretamente para esses ANRs, é preciso usar as seguintes
versões:
SDK do Crashlytics para Android v18.3.5 ou mais recente (BoM do Firebase v31.2.2 ou mais recente)
Plug-in do Gradle para Crashlytics v2.9.4 ou mais recente
Verifique se você está usando um local não padrão para suas bibliotecas compartilhadas.
Se os BuildIds estiverem faltando apenas nas bibliotecas compartilhadas do seu app, é provável
que você não esteja usando o local padrão para essas bibliotecas. Se
esse for o caso, talvez o Crashlytics não consiga localizar os
BuildIds associados. Recomendamos que você use o local
padrão para as bibliotecas compartilhadas.
Verifique se você não está removendo BuildIds durante o processo de build.
As dicas de solução de problemas a seguir se aplicam a ANRs e também a falhas
nativas.
Verifique se os BuildIds estão executando readelf -n nos seus programas binários. Se os
BuildIds estiverem faltando, adicione -Wl,--build-id às sinalizações do
sistema de build.
Verifique se você não está removendo BuildIds acidentalmente para reduzir
o tamanho do APK.
Se você mantiver as versões removidas e não removidas de uma biblioteca, não se esqueça de
apontar a versão correta no código.
Diferenças
entre os Relatórios de ANR no painel do Crashlytics e
no Google Play Console
Pode haver uma incompatibilidade na contagem de ANRs entre o Google Play e
o Crashlytics. Isso é esperado devido à diferença no mecanismo de
geração de relatórios e coleta de dados de ANR. O Crashlytics registra ANRs na próxima inicialização
do app, enquanto o Android vitals envia os dados após a ocorrência do ANR.
Além disso, o Crashlytics só exibe ANRs que ocorrem em dispositivos com o
Android 11 e versões mais recentes, enquanto o Google Play exibe ANRs de dispositivos que têm
o Google Play Services e o consentimento de coleta de dados aceito.
Diferenças
entre os stack traces do NDK no painel do Crashlytics e no logcat
Os conjuntos de ferramentas LLVM e GNU têm padrões e tratamentos distintos para o segmento somente
leitura dos binários do app, o que pode gerar stack traces inconsistentes
no Console do Firebase. Para atenuar isso, adicione as seguintes sinalizações do vinculador
ao seu processo de compilação:
Se você estiver usando o vinculador lld do conjunto de ferramentas LLVM, adicione:
-Wl,--no-rosegment
Se você estiver usando o vinculador ld.gold do conjunto de ferramentas GNU, adicione:
-Wl,--rosegment
Se você ainda estiver vendo inconsistências de stack trace (ou se nenhuma sinalização for
relevante para seu conjunto de ferramentas), adicione o seguinte ao processo
de compilação:
-fno-omit-frame-pointer
Como usar meu
próprio binário para NDK gerador de arquivos de símbolo do Breakpad?
O plug-in do Crashlytics agrupa um
gerador de arquivos de símbolo personalizados do Breakpad.
Se você prefere usar seu próprio binário para gerar arquivos de símbolo do Breakpad (por
exemplo, para criar todos os executáveis nativos da cadeia de builds direto da fonte), use a propriedade de extensão symbolGeneratorBinary opcional para especificar
o caminho para o executável.
Há duas formas de especificar o caminho para o binário gerador de arquivos de símbolo do Breakpad:
Opção 1: especificar o caminho usando a extensão
firebaseCrashlytics no arquivo build.gradle
Adicione o seguinte ao seu arquivo build.gradle.kts no nível do app:
Plug-in para Gradle v3.0.0 ou mais recente
android {
buildTypes {
release {
configure<CrashlyticsExtension> {
nativeSymbolUploadEnabled = true
// Add these optional fields to specify the path to the executable
symbolGeneratorType = "breakpad"
breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
}
}
}
}
versões anteriores do plug-in
android {
// ...
buildTypes {
// ...
release {
// ...
firebaseCrashlytics {
// existing; required for either symbol file generator
nativeSymbolUploadEnabled true
// Add this optional new block to specify the path to the executable
symbolGenerator {
breakpad {
binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
}
}
}
}
}
Opção 2: especificar o caminho usando uma linha de propriedade no
arquivo do Gradle
Você pode usar a propriedade com.google.firebase.crashlytics.breakpadBinary
para especificar o caminho para o executável.
É possível atualizar o arquivo de propriedades do Gradle manualmente ou atualizar o arquivo
usando a linha de comando. Por exemplo, para especificar o caminho pela linha,
use um comando como este:
Por que vejo falhas
em arquivos .kt marcadas como problemas .java?
Quando um app usa um ofuscador que não expõe a extensão do arquivo,
o Crashlytics gera cada problema com uma extensão de arquivo .java por padrão.
Para que o Crashlytics possa gerar problemas com a extensão de arquivo correta,
verifique se o app:
usa o Android para Gradle 4.2.0 ou com versão mais recente;
usa o R8 com a ofuscação ativada. Para atualizar seu app para o R8, siga este
documento.
Depois de fazer a atualização para a configuração descrita acima, é possível que
novos problemas .kt que são cópias de problemas .java existentes apareçam. Consulte as
Perguntas frequentes para saber mais sobre essa situação.
Por que vejo
problemas .kt que são cópias de problemas
.java existentes?
Em meados de dezembro de 2021, o Crashlytics melhorou a compatibilidade com apps
que usam Kotlin.
Até pouco tempo, os ofuscadores disponíveis não expunham a extensão do arquivo, então
o Crashlytics gerava cada problema com uma extensão de arquivo .java por padrão.
No entanto, a partir do Android para Gradle 4.2.0, o R8 se tornou compatível com as extensões de arquivos.
Com essa atualização, o Crashlytics pode determinar se cada classe usada no
app foi escrita em Kotlin e incluir o nome de arquivo correto na assinatura
do problema. Agora as falhas são atribuídas corretamente aos arquivos .kt,
se o app tiver a seguinte configuração:
O app usa o Android para Gradle 4.2.0 ou com versão mais recente.
O app usa o R8 com a ofuscação ativada.
Como as novas falhas agora incluem a extensão de arquivo correta nas assinaturas
dos problemas, é possível que você veja novos problemas .kt que são apenas cópias
de problemas existentes com o rótulo .java. No Console do Firebase, tentamos identificar
e comunicar se um novo problema .kt é uma possível cópia de um problema existente de .java.
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 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.
Suporte a plataformas
O Crashlytics oferece suporte ao armeabi?
O NDK do Firebase Crashlytics não oferece suporte ao ARMv5 (armeabi).
A compatibilidade com essa ABI foi removida a partir do NDK r17.
Problemas reabertos
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:
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").
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 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.
