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 Crashlytics é compatível com relatórios de 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+.
Pode haver uma incompatibilidade entre a contagem de ANRs entre o Google Play e o Crashlytics. Isso é esperado devido à diferença no mecanismo de coleta e comunicação de dados ANR. O Crashlytics informa os 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.
As cadeias 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 vinculador ao seu processo de compilação:
Se você estiver usando o vinculador
lldda cadeia de ferramentas LLVM, adicione:-Wl,--no-rosegmentSe você estiver usando o linker
ld.goldda cadeia de ferramentas GNU, adicione:-Wl,--rosegment
Se você ainda estiver vendo inconsistências de rastreamento de pilha (ou se nenhum dos sinalizadores for pertinente à sua cadeia de ferramentas), tente adicionar o seguinte ao seu processo de compilação:
-fno-omit-frame-pointer
O plug-in Crashlytics inclui um gerador de arquivo de símbolo Breakpad personalizado . Se você preferir usar seu próprio binário para gerar arquivos de símbolo do Breakpad (por exemplo, se preferir compilar todos os executáveis nativos em sua cadeia de compilaçã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 arquivos de símbolo do Breakpad de duas maneiras:
Opção 1 : especifique o caminho por meio da extensão
firebaseCrashlyticsem seu arquivobuild.gradleAdicione o seguinte ao seu 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 seu arquivo de propriedades Gradle ou atualizar o arquivo por meio da linha de comando. Por exemplo, para especificar o caminho por meio da linha de comando, use um comando como o seguinte:
./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 que é incompatível com o SDK do Firebase Crashlytics:
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
Essa 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 sua 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, verifique se o aplicativo usa a seguinte configuração:
- Usa o 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ê pode começar a ver novos problemas .kt que são duplicatas de problemas .java existentes. Consulte as Perguntas frequentes 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, portanto, 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 essa 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 a arquivos .kt (conforme apropriado) se seu aplicativo tiver a seguinte configuração:
- Seu aplicativo usa o Android Gradle 4.2.0 ou superior.
- Seu aplicativo usa R8 com ofuscação ativada.
Como as novas falhas agora incluem a extensão de arquivo correta em suas assinaturas de problemas, você pode ver novos problemas .kt que na verdade são apenas duplicatas de problemas rotulados .java existentes. No console do Firebase, tentamos identificar e comunicar a você se um novo problema .kt é uma possível duplicata de um problema rotulado .java existente.
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.
1 - ( CRASHED_USERS / ALL_USERS )
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.
Você pode visualizar o número de eventos app_exception para seu aplicativo no painel do Analytics. Observe que, devido a pequenas diferenças na forma como as falhas são processadas, o número app_exception exibido no painel do Google Analytics às vezes pode ser diferente do número usado no cálculo de usuários sem falhas.
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.
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
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 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.