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 v18.6.0+ (ou Firebase BoM v32.6.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.
Verifique especialmente se você está usando , no mínimo , a seguinte versão do SDK do Firebase para Google Analytics:
Android — v17.2.3+ (BoM v24.7.1+) .
O Crashlytics oferece suporte a relatórios ANR para aplicativos Android de dispositivos que executam o Android 11 e superior. A API subjacente que usamos para coletar ANRs ( getHistoricalProcessExitReasons ) é mais confiável do que SIGQUIT ou abordagens baseadas em watchdog. Esta API está disponível apenas em dispositivos Android 11+.
Se alguns de seus ANRs não tiverem BuildId , solucione o problema da seguinte maneira:
Certifique-se de estar usando uma versão atualizada do SDK do Crashlytics para Android e do plug-in Crashlytics Gradle.
Se estiver faltando
BuildIds para Android 11 e alguns ANRs do Android 12, é provável que você esteja usando um SDK desatualizado, um plug-in Gradle ou ambos. Para coletarBuildIds corretamente para esses ANRs, você precisa usar as seguintes versões:- SDK do Crashlytics para Android v18.3.5+ (Firebase BoM v31.2.2+)
- Plug-in Crashlytics Gradle v2.9.4+
Verifique se você está usando um local fora do padrão para suas bibliotecas compartilhadas.
Se você estiver faltando apenas
BuildIds para as bibliotecas compartilhadas do seu aplicativo, é provável que você não esteja usando o local padrão para bibliotecas compartilhadas. Se for esse o caso, o Crashlytics poderá não conseguir localizar osBuildIds associados. Recomendamos que você considere usar o local padrão para bibliotecas compartilhadas.Certifique-se de não remover
BuildIds durante o processo de construção.Observe que as dicas de solução de problemas a seguir se aplicam tanto a ANRs quanto a falhas nativas.
Verifique se os
BuildIdexistem executandoreadelf -nem seus binários. Se osBuildIds estiverem ausentes, adicione-Wl,--build-idaos sinalizadores do seu sistema de compilação.Verifique se você não está removendo acidentalmente os
BuildIds em um esforço para reduzir o tamanho do APK.Se você mantiver versões despojadas e não despojadas de uma biblioteca, certifique-se de apontar para a versão correta em seu código.
Pode haver uma incompatibilidade entre a contagem de ANRs entre o Google Play e o Crashlytics. Isto é esperado devido à diferença no mecanismo de recolha e comunicação de dados ANR. O Crashlytics relata ANRs na próxima inicialização do aplicativo, enquanto o Android Vitals envia dados de ANR após a ocorrência do ANR.
Além disso, o Crashlytics exibe apenas ANRs que ocorrem em dispositivos com Android 11+, em comparação com o Google Play, que exibe ANRs de dispositivos com Google Play Services e consentimento de coleta de dados aceito.
Os conjuntos de ferramentas LLVM e GNU têm padrões e tratamentos distintos para o segmento somente leitura dos binários do seu aplicativo, o que pode gerar rastreamentos de pilha inconsistentes no Console do Firebase. Para atenuar isso, adicione os seguintes sinalizadores de linker ao seu processo de construção:
Se você estiver usando o vinculador
lldda cadeia de ferramentas LLVM, adicione:-Wl,--no-rosegmentSe você estiver usando o vinculador
ld.golddo conjunto de ferramentas GNU, adicione:-Wl,--rosegment
Se você ainda estiver vendo inconsistências no rastreamento de pilha (ou se nenhum sinalizador for pertinente ao seu conjunto de ferramentas), tente adicionar o seguinte ao seu processo de construção:
-fno-omit-frame-pointer
O plug-in Crashlytics inclui um gerador de arquivo de símbolos Breakpad personalizado . Se você preferir usar seu próprio binário para gerar arquivos de símbolos Breakpad (por exemplo, se preferir construir todos os executáveis nativos em sua cadeia de construção a partir da fonte), use a propriedade de extensão opcional symbolGeneratorBinary para especificar o caminho para o executável.
Você pode especificar o caminho para o binário do gerador de arquivo de símbolo Breakpad de duas maneiras:
Opção 1 : especifique o caminho por meio da extensão
firebaseCrashlyticsem seu arquivobuild.gradleAdicione o seguinte ao arquivo
build.gradleno nível do aplicativo: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 : Especifique o caminho por meio de uma linha de propriedade em seu arquivo de propriedades Gradle
Você pode usar a propriedade
com.google.firebase.crashlytics.symbolGeneratorBinarypara especificar o caminho para o executável.Você pode atualizar manualmente o arquivo de propriedades do Gradle ou atualizá-lo por meio da linha de comando. Por exemplo, para especificar o caminho por meio da linha de comando, use um comando como este:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
Se você vir a seguinte exceção, é provável que esteja usando uma versão do DexGuard incompatível com o SDK do Firebase Crashlytics:
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
Esta exceção não trava seu aplicativo, mas impede que ele envie relatórios de falhas. Para corrigir isso:
Certifique-se de estar usando a versão mais recente do DexGuard 8.x. A versão mais recente contém regras exigidas pelo SDK do Firebase Crashlytics.
Se você não quiser alterar a versão do DexGuard, tente adicionar a seguinte linha às suas regras de ofuscação (no arquivo de configuração do DexGuard):
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
Quando um aplicativo 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, certifique-se de que seu aplicativo use a seguinte configuração:
- Usa Android Gradle 4.2.0 ou superior
- Usa R8 com ofuscação ativada. Para atualizar seu aplicativo para R8, siga esta documentação .
Observe que após atualizar para a configuração descrita acima, você poderá começar a ver novos problemas .kt que são duplicados de problemas .java existentes. Consulte o FAQ para saber mais sobre essa circunstância.
A partir de meados de dezembro de 2021, o Crashlytics melhorou o suporte para aplicativos que usam Kotlin.
Até recentemente, 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 Gradle 4.2.0, o R8 oferece suporte a extensões de arquivo.
Com esta atualização, o Crashlytics agora pode determinar se cada classe usada no aplicativo está escrita em Kotlin e incluir o nome de arquivo correto na assinatura do problema. As falhas agora são atribuídas corretamente aos arquivos .kt (conforme apropriado) se o seu aplicativo tiver a seguinte configuração:
- Seu aplicativo usa o Android Gradle 4.2.0 ou superior.
- Seu aplicativo usa R8 com a ofuscação ativada.
Como novas falhas agora incluem a extensão de arquivo correta em suas assinaturas de problemas, você poderá ver novos problemas .kt que são, na verdade, apenas duplicatas de problemas existentes rotulados .java . No console do Firebase, tentamos identificar e comunicar a você se um novo problema .kt é uma possível duplicação de um problema existente rotulado .java .
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.
Suporte de plataforma
O Firebase Crashlytics NDK não é compatível com ARMv5 (armeabi). O suporte para esta ABI foi removido a partir do NDK r17.
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.