Solução de problemas e perguntas frequentes do Crashlytics

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:

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 BuildId s 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 coletar BuildId s 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 BuildId s 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 os BuildId s associados. Recomendamos que você considere usar o local padrão para bibliotecas compartilhadas.

  • Certifique-se de não remover BuildId s 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 BuildId existem executando readelf -n em seus binários. Se os BuildId s estiverem ausentes, adicione -Wl,--build-id aos sinalizadores do seu sistema de compilação.

    • Verifique se você não está removendo acidentalmente os BuildId s 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 lld da cadeia 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 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 firebaseCrashlytics em seu arquivo build.gradle

    Adicione o seguinte ao arquivo build.gradle no 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.symbolGeneratorBinary para 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:

  1. 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.

  2. 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:

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:

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:

  1. 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").
  2. Você corrige esse bug rapidamente, fecha o problema "A" e lança uma nova versão do seu aplicativo.
  3. 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.