Resolução de problemas e Perguntas frequentes do Crashlytics

Esta página oferece ajuda para a resolução de problemas e respostas a perguntas frequentes sobre a utilização do Crashlytics. Se não conseguir encontrar o que procura ou precisar de ajuda adicional, contacte o apoio técnico do Firebase.

Nesta página, pode encontrar informações sobre os seguintes tipos de tópicos:

• Resolução de problemas gerais, incluindo perguntas sobre a apresentação de dados ou o trabalho com dados na consola Firebase e perguntas sobre problemas recorrentes.

• Apoio técnico específico da plataforma, incluindo perguntas específicas sobre plataformas Apple, Android e Unity.

• Apoio técnico para integrações, incluindo perguntas sobre BigQuery.

Resolução de problemas gerais/Perguntas frequentes

Ver formatos diferentes (e, por vezes, "variantes") para alguns problemas na tabela Problemas

Pode reparar em dois formatos diferentes para os problemas apresentados na tabela Problemas na consola Firebase. Também pode reparar numa funcionalidade denominada "variantes" em alguns dos seus problemas. Veja o motivo!

No início de 2023, implementámos um motor de análise melhorado para agrupar eventos, bem como um design atualizado e algumas funcionalidades avançadas para novos problemas (como variantes!). Consulte a nossa recente publicação no blogue para ver todos os detalhes, mas pode ler abaixo os destaques.

O Crashlytics analisa todos os eventos da sua app (como falhas de sistema, não fatais e ANRs) e cria grupos de eventos denominados problemas. Todos os eventos num problema têm um ponto de falha comum.

Para agrupar eventos nestes problemas, o motor de análise melhorado analisa agora muitos aspetos do evento, incluindo os frames no rastreio da pilha, a mensagem de exceção, o código de erro e outras caraterísticas da plataforma ou do tipo de erro.

No entanto, neste grupo de eventos, os rastreios de pilha que originam a falha podem ser diferentes. Um rastreio de pilha diferente pode significar uma causa principal diferente. Para representar esta possível diferença num problema, criamos agora variantes nos problemas. Cada variante é um subgrupo de eventos num problema que têm o mesmo ponto de falha e um rastreio de pilha semelhante. Com as variantes, pode depurar os rastreios de pilha mais comuns num problema e determinar se diferentes causas principais estão a originar a falha.

Veja o que vai sentir com estas melhorias:

• Metadados reformulados apresentados na linha do problema
  Agora, é mais fácil compreender e resolver problemas na sua app.

• Menos problemas duplicados
  Uma alteração do número da linha não resulta num novo problema.

• Depuração mais fácil de problemas complexos com várias causas principais
  Use variantes para depurar os rastreios de pilha mais comuns num problema.

• Alertas e sinais mais significativos
  Um novo problema representa efetivamente um novo erro.

• Pesquisa mais avançada
  Cada problema contém mais metadados pesquisáveis, como o tipo de exceção e o nome do pacote.

Veja como estas melhorias estão a ser implementadas:

• Quando recebemos novos eventos da sua app, verificamos se correspondem a um problema existente.

• Se não houver correspondência, aplicamos automaticamente o nosso algoritmo de agrupamento de eventos mais inteligente ao evento e criamos um novo problema com o design dos metadados renovado.

Esta é a primeira grande atualização que estamos a fazer à nossa agrupamento de eventos. Se tiver feedback ou encontrar problemas, informe-nos apresentando um relatório.

Não vê registos de rastreio

Se não estiver a ver registos de rastreio (iOS+ | Android | Flutter | Unity), recomendamos que verifique a configuração da sua app para Google Analytics. Certifique-se de que cumpre os seguintes requisitos:

• Ativou Google Analytics no seu projeto do Firebase.

• Ativou a partilha de dados para Google Analytics. Saiba mais sobre esta definição em Faça a gestão das definições de partilha de dados do Analytics

• Adicionou à sua app o SDK do Firebase para Google Analytics: iOS+ | Android | Flutter | Unity.
  Este SDK tem de ser adicionado além do SDK Crashlytics.

• Está a usar as versões mais recentes do SDK do Firebase para todos os produtos que usa na sua app (iOS+ | Android | Flutter | Unity).

  Para as plataformas Apple e as apps Android, verifique especialmente se está a usar, no mínimo, a seguinte versão do SDK do Firebase para Google Analytics: iOS+: v6.3.1 ou superior (v8.9.0 ou superior para macOS e tvOS) | Android: v17.2.3 ou superior (BoM v24.7.1 ou superior).

Não vê alertas de velocidade

Se não estiver a ver alertas de velocidade, certifique-se de que está a usar o: SDK do Crashlytics v18.6.0 ou superior (ou Firebase BoM v32.6.0 ou superior).

Não vê métricas sem falhas (ou vê métricas não fiáveis)

Se não estiver a ver métricas sem falhas de sistema (como utilizadores e sessões sem falhas de sistema) ou estiver a ver métricas não fiáveis, verifique o seguinte:

• Certifique-se de que está a usar o SDK do Crashlytics v18.6.0 ou superior (ou Firebase BoM v32.6.0 ou superior).

• Certifique-se de que as definições de recolha de dados não estão a afetar a qualidade das métricas sem falhas:

  • Se ativar os relatórios de aceitação desativando os relatórios de falhas automáticos, as informações de falhas só podem ser enviadas para Crashlytics por utilizadores que aceitaram explicitamente a recolha de dados. Assim, a precisão das métricas sem falhas de sistema é afetada, uma vez que o Crashlytics só tem informações sobre falhas de sistema destes utilizadores que aceitaram (em vez de todos os seus utilizadores). Isto significa que as suas métricas sem falhas podem ser menos fiáveis e menos representativas da estabilidade geral da sua app.

  • Se tiver a recolha automática de dados desativada, pode usar sendUnsentReports para enviar relatórios em cache no dispositivo para Crashlytics. A utilização deste método envia dados de falhas do sistema para o Crashlytics, mas não envia dados de sessões, o que faz com que os gráficos da consola apresentem valores baixos ou nulos para as métricas sem falhas do sistema.

Como são calculados os utilizadores sem falhas de sistema?

Consulte o artigo Compreenda as métricas sem falhas.

Quem pode ver, escrever e eliminar notas num problema?

As notas permitem que os membros do projeto comentem problemas específicos com perguntas, atualizações de estado, etc.

Quando um membro do projeto publica uma nota, esta é etiquetada com o email da respetiva Conta Google. Este endereço de email é visível, juntamente com a nota, para todos os membros do projeto com acesso para ver a nota.

A descrição seguinte descreve o acesso necessário para ver, escrever e eliminar notas:

• Os membros do projeto com qualquer uma das seguintes funções podem ver e eliminar notas existentes, bem como escrever novas notas num problema.

  • Proprietário ou editor do projeto, Administrador do Firebase, Administrador de qualidade, ou Administrador do Crashlytics

• Os membros do projeto com qualquer uma das seguintes funções podem ver as notas publicadas num problema, mas não podem eliminar nem escrever uma nota.

  • Leitor do projeto, Leitor do Firebase, Leitor de qualidade, ou Leitor do Crashlytics

O que é um problema regredido?

Um problema sofreu uma regressão quando o fechou anteriormente, mas o Crashlytics recebe uma nova denúncia de que o problema voltou a ocorrer. Crashlytics reabre automaticamente estes problemas regressivos para que possa resolvê-los conforme adequado para a sua app.

Segue-se um cenário de exemplo que explica como o Crashlytics categoriza um problema como uma regressão:

1. Pela primeira vez, o Crashlytics recebe um relatório de falhas sobre a falha "A". Crashlytics abre um problema correspondente para essa falha (problema "A").
2. Corrige este erro rapidamente, fecha o problema "A" e, em seguida, lança uma nova versão da sua app.
3. Crashlytics recebe outro relatório sobre o problema "A" depois de o ter fechado.
   • Se o relatório for de uma versão da app que o Crashlytics conhecia quando fechou o problema (o que significa que a versão tinha enviado um relatório de falhas para qualquer falha), o Crashlytics não considera o problema como tendo regredido. O problema vai permanecer encerrado.
   • Se o relatório for de uma versão da app que Crashlytics não conhecia quando fechou o problema (o que significa que a versão nunca enviou nenhum relatório de falhas para nenhuma falha), o Crashlytics considera que o problema regrediu e reabre o problema.

Nota: antes de fevereiro de 2022, o Crashlytics categorizava um problema como uma regressão quando esse problema voltava a ocorrer em qualquer versão da app, mesmo para versões da app que conhecíamos quando fechou o problema. Isto resultou na Crashlytics identificação por vezes incorreta de regressões. Agora, usamos a convenção descrita acima.

Quando um problema regride, enviamos um alerta de deteção de regressão e adicionamos um sinal de regressão ao problema para informar que o Crashlytics reabriu o problema. Se não quiser que um problema seja reaberto devido ao nosso algoritmo de regressão, "desative o som" do problema em vez de o fechar.

Por que motivo estou a ver problemas regredidos para versões mais antigas da app?

Se um relatório for de uma versão antiga da app que nunca enviou relatórios de falhas quando fechou o problema, o Crashlytics considera que o problema regrediu e volta a abri-lo.

Esta situação pode ocorrer no seguinte caso: corrigiu um erro e lançou uma nova versão da sua app, mas ainda tem utilizadores em versões anteriores sem a correção de erros. Se, por acaso, uma dessas versões anteriores nunca tivesse enviado relatórios de falhas quando fechou o problema e esses utilizadores começassem a encontrar o erro, esses relatórios de falhas acionariam um problema de regressão.

Se não quiser que um problema seja reaberto devido ao nosso algoritmo de regressão, "desative o som" do problema em vez de o fechar.

Nota: antes de fevereiro de 2022, o Crashlytics categorizava um problema como uma regressão quando esse problema voltava a ocorrer em qualquer versão da app, mesmo para versões da app que conhecíamos quando fechou o problema. Isto resultou na Crashlytics identificação por vezes incorreta de regressões. Agora, usamos a convenção descrita acima.

Se vir muitas regressões identificadas incorretamente antes de fevereiro de 2022, pode voltar a fechá-las para impedir que sejam reabertas.

---

Apoio técnico específico da plataforma

As secções seguintes oferecem suporte para a resolução de problemas específicos da plataforma e perguntas frequentes: iOS+ | Android | Unity.

Suporte de plataformas Apple

Os dSYMs estão em falta/não estão a ser carregados

Para carregar os dSYMs do seu projeto e obter resultados detalhados, verifique o seguinte:

1. Certifique-se de que a fase de compilação do seu projeto contém o Crashlyticsscript de execução, que permite ao Xcode carregar os dSYMs do seu projeto no momento da compilação (leia o artigo Inicializar o Crashlytics para obter instruções sobre como adicionar o script). Depois de atualizar o projeto, force uma falha de sistema e confirme que a falha de sistema aparece no painel de controlo do Crashlytics.

2. Se vir um alerta "dSYM em falta" na consola Firebase, verifique o Xcode para se certificar de que está a produzir corretamente dSYMs para a compilação.

3. Se o Xcode estiver a produzir dSYMs corretamente e continuar a ver dSYMs em falta, é provável que a ferramenta de script de execução esteja a ficar bloqueada durante a transferência dos dSYMs. Neste caso, experimente cada uma das seguintes ações:

   • Certifique-se de que está a usar a versão mais recente do Crashlytics.

   • Carregue os ficheiros dSYM em falta manualmente:

     • Opção 1: use a opção "Arraste e solte" baseada na consola no separador dSYMs para carregar um arquivo ZIP que contenha os ficheiros dSYM em falta.
     • Opção 2: use o script upload-symbols para carregar os ficheiros dSYM em falta para os UUIDs fornecidos no separador dSYMs.

4. Se continuar a ver dSYMs em falta ou os carregamentos continuarem sem êxito, contacte o apoio técnico do Firebase e certifique-se de que inclui os seus registos.

As falhas de sistema estão mal simbolizadas

Se os rastreios da pilha parecerem ter poucos símbolos, verifique o seguinte:

• Se os frames da biblioteca da sua app não tiverem referências ao código da app, certifique-se de que -fomit-frame-pointer não está definido como um indicador de compilação.

• Se vir vários frames (Missing) para a biblioteca da sua app, verifique se existem dSYMs opcionais indicados como em falta (para a versão da app afetada) no Crashlytics separador dSYMs da Firebase console. Se for o caso, siga o passo de resolução de problemas "Alerta de dSYM em falta" nas Perguntas frequentes sobre dSYMs em falta/não carregados nesta página. Tenha em atenção que o carregamento destes dSYMs não simboliza falhas de sistema que já ocorreram, mas ajuda a garantir a simbolização de falhas de sistema futuras.

Posso usar o Crashlytics para macOS ou tvOS?

Sim, pode implementar Crashlytics em projetos do macOS e tvOS. Certifique-se de que inclui a versão 8.9.0 ou superior do SDK do Firebase para Google Analytics, para que as falhas de sistema tenham acesso às métricas recolhidas pelo Google Analytics (utilizadores sem falhas de sistema, versão mais recente, alertas de velocidade e registos de rastreio).

Posso usar o Crashlytics num projeto do Firebase com várias apps em diferentes plataformas Apple?

Agora, pode comunicar falhas de várias apps num único projeto do Firebase, mesmo quando as apps são criadas para diferentes plataformas Apple (por exemplo, iOS, tvOS e Mac Catalyst). Anteriormente, tinha de separar as apps em projetos do Firebase individuais se contivessem o mesmo ID do pacote.

---

Apoio técnico do Android

Por que motivo os ANRs só são comunicados para o Android 11 e superior?

O Crashlytics suporta relatórios de ANRs para apps Android em dispositivos com o Android 11 e superior. A API subjacente que usamos para recolher ANRs (getHistoricalProcessExitReasons) é mais fiável do que as abordagens baseadas em SIGQUIT ou watchdog. Esta API está disponível apenas em dispositivos com o Android 11 ou superior.

Por que motivo alguns ANRs não têm BuildIds?

Se alguns dos seus ANRs não tiverem BuildIds, resolva os problemas da seguinte forma:

• Certifique-se de que está a usar um Crashlytics Android SDK atualizado e Crashlytics uma versão do plug-in do Gradle.

  Se estiverem em falta BuildIds para o Android 11 e alguns ANRs do Android 12, é provável que esteja a usar um SDK, um plugin do Gradle ou ambos desatualizados. Para recolher corretamente BuildIds para estes ANRs, tem de usar as seguintes versões:

  • Crashlytics Android SDK v18.3.5 ou superior (Firebase BoM v31.2.2 ou superior)
  • Crashlytics Plugin do Gradle v2.9.4 ou superior

• Verifique se está a usar uma localização não padrão para as suas bibliotecas partilhadas.

  Se só faltaremBuildIds para as bibliotecas partilhadas da sua app, é provável que não esteja a usar a localização padrão para as bibliotecas partilhadas. Se for o caso, Crashlytics pode não conseguir localizar os BuildIds associados. Recomendamos que considere usar a localização padrão para bibliotecas partilhadas.

• Certifique-se de que não está a remover BuildIds durante o processo de criação.

  Tenha em atenção que as seguintes sugestões de resolução de problemas aplicam-se a ANRs e falhas nativas.

  • Verifique se os BuildIds existem executando readelf -n nos seus ficheiros binários. Se os BuildIds estiverem ausentes, adicione -Wl,--build-id às flags do seu sistema de compilação.

  • Verifique se não está a remover involuntariamente os BuildIds para tentar reduzir o tamanho do APK.

  • Se mantiver versões com e sem informações de depuração de uma biblioteca, certifique-se de que aponta para a versão correta no seu código.

Diferenças entre os relatórios de ANR no painel de controlo Crashlytics e na Google Play Console

Pode haver uma incompatibilidade entre a contagem de ANRs entre o Google Play e o Android Vitals. Isto é esperado devido à diferença no mecanismo de recolha e comunicação de dados de ANRs. O Android Vitals comunica ANRs quando a app é iniciada novamente, enquanto o Google Play envia dados de ANRs após a ocorrência do ANR.CrashlyticsCrashlytics

Além disso, Crashlyticssó apresenta ANRs que ocorrem em dispositivos com o Android 11 ou superior, em comparação com o Google Play, que apresenta ANRs de dispositivos com os Serviços do Google Play e o consentimento de recolha de dados aceite.

Por que motivo vejo falhas de sistema em ficheiros .kt etiquetados como problemas .java?

Quando uma app usa um obfuscador que não expõe a extensão de ficheiro, o Crashlytics gera cada problema com uma extensão de ficheiro .java por predefinição.

Para que o Crashlytics possa gerar problemas com a extensão de ficheiro correta, certifique-se de que a sua app usa a seguinte configuração:

• Usa o Android Gradle 4.2.0 ou superior
• Usa o R8 com a ocultação ativada. Para atualizar a sua app para o R8, siga esta documentação.

Tenha em atenção que, após a atualização para a configuração descrita acima, pode começar a ver novos problemas .kt que são duplicados de problemas .java existentes. Consulte as Perguntas frequentes para saber mais sobre essa circunstância.

Por que motivo vejo .kt problemas que são duplicados de problemas .java existentes?

A partir de meados de dezembro de 2021, Crashlyticsmelhorámos o suporte para aplicações que usam Kotlin.

Até recentemente, os obfuscadores disponíveis não expunham a extensão do ficheiro, pelo que, por predefinição, Crashlyticsgeravam cada problema com uma extensão de ficheiro .java. No entanto, a partir do Android Gradle 4.2.0, o R8 suporta extensões de ficheiros.

Com esta atualização, o Crashlytics pode agora determinar se cada classe usada na app está escrita em Kotlin e incluir o nome de ficheiro correto na assinatura do problema. As falhas de sistema são agora corretamente atribuídas a ficheiros .kt (conforme adequado) se a sua app tiver a seguinte configuração:

• A sua app usa o Android Gradle 4.2.0 ou superior.
• A sua app usa o R8 com a ocultação ativada.

Uma vez que as novas falhas incluem agora a extensão do ficheiro correta nas respetivas assinaturas de problemas, pode ver novos problemas .kt que são, na verdade, apenas duplicados de problemas existentes etiquetados como .java. Na consola Firebase, tentamos identificar e comunicar-lhe se um novo problema .kt é um possível duplicado de um problema existente etiquetado como .java.

Não está a ter falhas de sistema com o Dexguard

Se vir a seguinte exceção, é provável que esteja a usar uma versão do DexGuard incompatível com o SDK Firebase Crashlytics:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

Esta exceção não provoca falhas de sistema na sua app, mas impede-a de enviar relatórios de falhas de sistema. Para corrigir o problema:

1. Certifique-se de que está a usar a versão mais recente do DexGuard 8.x. A versão mais recente contém regras exigidas pelo SDK Firebase Crashlytics.

2. Se não quiser alterar a versão do DexGuard, experimente adicionar a seguinte linha às regras de ofuscação (no ficheiro de configuração do DexGuard):

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

Como atualizar para o Crashlyticsplugin do Gradle v3?

A versão mais recente do plugin do Gradle é uma versão principal (v3.0.0) e moderniza o SDK ao descontinuar o suporte para versões inferiores do Gradle e do plugin do Android para o Gradle.Crashlytics Além disso, as alterações nesta versão resolvem problemas com o AGP v8.1 e melhoram o suporte para apps nativas e compilações personalizadas.

Requisitos mínimos

O plug-in do Gradle v3 tem os seguintes requisitos mínimos:Crashlytics

• Plugin do Android para o Gradle 8.1 ou superior
  Atualize este plugin através do Assistente de atualização do plugin do Android para o Gradle na versão mais recente do Android Studio.

• google-servicesPlugin do Gradle 4.4.1 ou superior do Firebase
  Atualize este plugin especificando a versão mais recente no ficheiro de compilação do Gradle do seu projeto, da seguinte forma:

Kotlin

plugins {
  id("com.android.application") version "8.1.4" apply false
  id("com.google.gms.google-services") version "4.4.4" apply false
  ...
}

Groovy

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.4.4' apply false
  ...
}

Alterações à extensão Crashlytics

Com a v3 do plugin do Gradle, a extensão Crashlytics tem as seguintes alterações interruptivas:Crashlytics

• Removeu a extensão do bloco defaultConfig do Android. Em alternativa, deve configurar cada variante.

• O campo descontinuado mappingFile foi removido. Em alternativa, o ficheiro de mapeamento unido é agora fornecido automaticamente.

• O campo descontinuado strippedNativeLibsDir foi removido. Em alternativa, deve usar unstrippedNativeLibsDir para todas as bibliotecas nativas.

• O campo unstrippedNativeLibsDir foi alterado para cumulativo.

  Veja um exemplo com vários diretórios

  buildTypes {
    release {
      configure<CrashlyticsExtension> {
        nativeSymbolUploadEnabled = true
        unstrippedNativeLibsDir = file("MY/NATIVE/LIBS")
      }
    }
    productFlavors {
      flavorDimensions += "feature"
      create("basic") {
        dimension = "feature"
        // ...
      }
      create("featureX") {
        dimension = "feature"
        configure<CrashlyticsExtension> {
          unstrippedNativeLibsDir = file("MY/FEATURE_X/LIBS")
        }
      }
    }
  }

  A tarefa uploadCrashlyticsSymbolFilesBasicRelease carrega apenas os símbolos em MY/NATIVE/LIBS, mas uploadCrashlyticsSymbolFilesFeatureXRelease carrega símbolos em MY/NATIVE/LIBS e MY/FEATURE_X/LIBS.

• O campo de encerramento symbolGenerator foi substituído por dois novos campos de nível superior:

  • symbolGeneratorType, uma string de "breakpad" (predefinição) ou "csym".
  • breakpadBinary, um ficheiro de uma substituição binária dump_syms local.

Exemplo de como atualizar a extensão

Kotlin

Antes	buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGenerator( closureOf<SymbolGenerator> { symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } ) } } }
Agora na v3	buildTypes { release { configure<CrashlyticsExtension> { // ... symbolGeneratorType = "breakpad" breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } }

Groovy

Antes	buildTypes { release { firebaseCrashlytics { // ... symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }
Agora na v3	buildTypes { release { firebaseCrashlytics { // ... symbolGeneratorType "breakpad" breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } }

Apoio técnico específico do Android-NDK

Diferenças entre os rastreios de pilha do NDK no painel de controlo do Crashlytics e no logcat

As cadeias de ferramentas LLVM e GNU têm predefinições e tratamentos distintos para o segmento só de leitura dos binários da sua app, o que pode gerar rastreios de pilha inconsistentes na consola Firebase. Para mitigar esta situação, adicione as seguintes flags do linker ao processo de compilação:

• Se estiver a usar o linker lld da cadeia de ferramentas LLVM, adicione:

  -Wl,--no-rosegment

• Se estiver a usar o linker ld.gold da cadeia de ferramentas GNU, adicione:

  -Wl,--rosegment

Se continuar a ver inconsistências na rastreabilidade da pilha (ou se nenhum dos flags for pertinente para a sua cadeia de ferramentas), experimente adicionar o seguinte ao processo de compilação:

-fno-omit-frame-pointer

Como posso usar o meu próprio ficheiro binário do gerador de ficheiros de símbolos do Breakpad para o NDK?

O plug-in Crashlytics inclui um gerador de ficheiros de símbolos do Breakpad personalizado. Se preferir usar o seu próprio binário para gerar ficheiros de símbolos do Breakpad (por exemplo, se preferir compilar todos os executáveis nativos na sua cadeia de compilação a partir da origem), use a propriedade de extensão symbolGeneratorBinary opcional para especificar o caminho para o executável.

Nota: a versão Linux do gerador de ficheiros de símbolos do Breakpad é necessária para os binários do Android.

Pode especificar o caminho para o ficheiro binário do gerador de ficheiros de símbolos do Breakpad de uma de duas formas:

• Opção 1: especifique o caminho através da extensão no ficheiro build.gradlefirebaseCrashlytics

  Adicione o seguinte ao ficheiro build.gradle.kts ao nível da app:

  Plugin do Gradle v3.0.0 ou superior

  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 inferiores do plugin

  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 através de uma linha de propriedade no ficheiro properties do Gradle

  Pode usar a propriedade com.google.firebase.crashlytics.breakpadBinary para especificar o caminho para o ficheiro executável.

  Pode atualizar manualmente o ficheiro de propriedades do Gradle ou atualizar o ficheiro através da linha de comandos. Por exemplo, para especificar o caminho através da linha de comandos, use um comando como o seguinte:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

O Crashlytics suporta armeabi?

O Firebase Crashlytics NDK não suporta ARMv5 (armeabi). O suporte para esta ABI foi removido a partir do NDK r17.

---

Apoio técnico do Unity

Ver rastreios de pilhas não simbolizados para apps Android no painel de controlo do Crashlytics

Se estiver a usar o Unity IL2CPP e vir rastreios de pilha sem símbolos, experimente o seguinte:

1. Certifique-se de que está a usar a versão 8.6.1 ou superior do SDK do Unity.Crashlytics

2. Certifique-se de que tem a configuração e está a executar o comando FirebaseCLIcrashlytics:symbols:upload para gerar e carregar o ficheiro de símbolos.

   Tem de executar este comando da CLI sempre que criar uma versão ou qualquer compilação para a qual queira ver rastreios de pilha com símbolos na consola Firebase. Saiba mais em Obtenha relatórios de falhas legíveis.

Pode usar o Crashlytics com apps que usam IL2CPP?

Sim, o Crashlytics pode apresentar rastreios de pilha simbolizados para as suas apps que usam IL2CPP. Esta capacidade está disponível para apps lançadas em plataformas Android ou Apple. Saiba o que tem de fazer:

1. Certifique-se de que está a usar a versão 8.6.0 ou superior do SDK do Unity.Crashlytics

2. Conclua as tarefas necessárias para a sua plataforma:

   • Para apps da plataforma Apple: não são necessárias ações especiais. Para apps da plataforma Apple, o plug-in do editor do Firebase Unity configura automaticamente o seu projeto do Xcode para carregar símbolos.

   • Para apps Android: certifique-se de que tem a configuração necessária e está a executar o comando Firebase CLI crashlytics:symbols:upload para gerar e carregar o ficheiro de símbolos.

     Tem de executar este comando da CLI sempre que criar uma versão ou qualquer compilação para a qual queira ver rastreios de pilha com símbolos na consola Firebase. Saiba mais em Obtenha relatórios de falhas legíveis.

Comunicação de exceções não detetadas como fatais

Crashlytics pode comunicar exceções não capturadas como fatais (a partir da v10.4.0 do SDK do Unity). As seguintes Perguntas frequentes ajudam a explicar a lógica e as práticas recomendadas para usar esta funcionalidade.

Por que motivo uma app deve comunicar exceções não capturadas como erros fatais?

Ao comunicar exceções não capturadas como fatais, recebe uma indicação mais realista das exceções que podem tornar o jogo injogável, mesmo que a app continue a ser executada.

Tenha em atenção que, se começar a comunicar erros fatais, a percentagem de utilizadores sem falhas de sistema (CFU) vai provavelmente diminuir, mas a métrica de CFU vai ser mais representativa das experiências dos utilizadores finais com a sua app.

Importante: a denúncia de exceções não capturadas como fatais não afeta o seu Android Vitals. Os erros fatais comunicados em Crashlytics só são visíveis para si, para que possa descobrir e corrigir problemas nas suas apps e jogos.

Que exceções vão ser comunicadas como fatais?

Para que o Crashlytics comunique uma exceção não capturada como fatal, têm de ser cumpridas as duas condições seguintes:

• Durante a inicialização na sua app, a propriedade ReportUncaughtExceptionsAsFatal tem de estar definida como true.

• A sua app (ou uma biblioteca incluída) gera uma exceção que não é capturada. Uma exceção criada, mas não lançada, não é considerada não capturada.

Depois de ativar os relatórios de exceções não capturadas como fatais, tenho muitas novas exceções fatais. Como posso processar corretamente estas exceções?

Quando começar a receber relatórios das suas exceções não capturadas como fatais, seguem-se algumas opções para processar estas exceções não capturadas:

• Considere como pode começar a detetar e processar estas exceções não processadas.
• Considere diferentes opções para registar exceções na consola de depuração do Unity e no Crashlytics.

Capturar e processar exceções lançadas

As exceções são criadas e lançadas para refletir estados inesperados ou excecionais. A resolução dos problemas refletidos por uma exceção lançada envolve a devolução do programa a um estado conhecido (um processo conhecido como tratamento de exceções).

É uma prática recomendada captar e processar todas as exceções previstas, a menos que não seja possível devolver o programa a um estado conhecido.

Para controlar que tipos de exceções são detetados e processados por que código, inclua o código que pode gerar uma exceção num bloco try-catch. Certifique-se de que as condições nas declarações catch são o mais restritas possível para processar as exceções específicas de forma adequada.

Registe exceções no Unity ou Crashlytics

Existem várias formas de registar exceções no Unity ou Crashlytics para ajudar a resolver o problema.

Quando usar Crashlytics, seguem-se as duas opções mais comuns e recomendadas:

• Opção 1: imprimir na consola do Unity, mas não comunicar ao Crashlytics, durante o desenvolvimento ou a resolução de problemas

  • Imprima na consola do Unity com Debug.Log(exception), Debug.LogWarning(exception) e Debug.LogError(exception), que imprimem o conteúdo da exceção na consola do Unity e não voltam a lançar a exceção.

• Opção 2: carregue para o Crashlytics para relatórios consolidados no painel de controlo do Crashlytics para as seguintes situações:

  • Se uma exceção valer a pena registar para depurar um possível evento Crashlytics subsequente, use Crashlytics.Log(exception.ToString()).
  • Se uma exceção ainda deve ser comunicada ao Crashlytics apesar de ter sido capturada e processada, use Crashlytics.LogException(exception) para a registar como um evento não fatal.

No entanto, se quiser comunicar manualmente um evento fatal ao Unity Cloud Diagnostics, pode usar Debug.LogException. Esta opção imprime a exceção na consola do Unity, como a opção 1, mas também lança a exceção (tenha ou não sido lançada ou capturada). Gera o erro não localmente. Isto significa que mesmo um bloco Debug.LogException(exception) com try-catch continua a resultar numa exceção não capturada.

Por conseguinte, chame Debug.LogException se e apenas se quiser fazer tudo o seguinte:

• Para imprimir a exceção na consola do Unity.
• Para carregar a exceção para o Crashlytics como um evento fatal.
• Para acionar a exceção, faça com que seja tratada como uma exceção não detetada e faça com que seja comunicada ao Unity Cloud Diagnostics.

Tenha em atenção que, se quiser imprimir uma exceção capturada na consola do Unity e carregar para o Crashlytics como um evento não fatal, faça o seguinte:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}

---

Apoio técnico para integrações

A app também usa o SDK Google Mobile Ads, mas não está a ter falhas de sistema

Se o seu projeto usar o Crashlytics juntamente com o SDK Google Mobile Ads, é provável que os relatórios de falhas estejam a interferir no registo de controladores de exceções. Para corrigir o problema, desative os relatórios de falhas no SDK Mobile Ads chamando disableSDKCrashReporting.

Onde está localizado o meu conjunto de dados do BigQuery?

O Firebase exporta dados para a localização do conjunto de dados que selecionou quando configurou a exportação de dados para o BigQuery.

• Esta localização aplica-se ao conjunto de dados Crashlytics e ao conjunto de dados de sessões do Firebase (se os dados de sessões estiverem ativados para exportação).

• Esta localização só se aplica aos dados exportados para o BigQuery e não afeta a localização dos dados armazenados para utilização no painel de controlo Crashlytics da consola Firebase ou no Android Studio.

• Após a criação de um conjunto de dados, não é possível alterar a respetiva localização. No entanto, pode copiar o conjunto de dados para uma localização diferente ou mover (recriar) manualmente o conjunto de dados para uma localização diferente. Para saber mais, consulte o artigo Altere a localização das exportações existentes.

Problemas após a atualização para a nova infraestrutura de exportação para BigQuery?

Em meados de outubro de 2024, a Crashlytics lançou uma nova infraestrutura para a exportação em lote de dados da Crashlytics para o BigQuery.

Todos os projetos do Firebase foram atualizados automaticamente para a nova infraestrutura de exportação em lote a partir de 2 de março de 2026.

Nota: esta atualização da infraestrutura aplica-se apenas às exportações de falhas de sistema em Crashlytics lote e não se aplica a sessões nem a exportações de streaming.

Diferenças importantes entre a infraestrutura de exportação antiga e a nova infraestrutura de exportação

• A nova infraestrutura suporta Crashlyticslocalizações de conjuntos de dados fora dos Estados Unidos.

  • Exportação ativada antes de meados de outubro de 2024 e atualizada para a nova infraestrutura de exportação. Agora, pode alterar opcionalmente a localização da exportação de dados.

  • Exportação ativada em meados de outubro de 2024 ou posteriormente: foi-lhe pedido que selecionasse uma localização para a exportação de dados durante a configuração.

• A nova infraestrutura não suporta o preenchimento de dados anteriores à ativação da exportação.

  • A infraestrutura antiga suportava o preenchimento de dados até 30 dias antes da data em que ativou a exportação.

  • A nova infraestrutura suporta preenchimentos até aos últimos 30 dias ou para a data mais recente em que ativou a exportação para o BigQuery (consoante o que for mais recente).

• A nova infraestrutura denomina as tabelas de lotes BigQuerycom os identificadores definidos para as suas apps Firebase no projeto do Firebase.

  • A infraestrutura antiga escrevia dados em tabelas de lotes com nomes baseados nos IDs dos pacotes ou nos nomes dos pacotes no ficheiro binário da sua app.

  • A nova infraestrutura escreve dados em tabelas de lotes com nomes baseados nos IDs dos pacotes ou nos nomes dos pacotes definidos para as suas apps Firebase registadas no seu projeto do Firebase.

Se o nome da tabela de lotes antiga não corresponder ao identificador da app do Firebase

Se o nome da tabela de lotes antiga não corresponder ao ID do pacote ou ao nome do pacote definido para a sua app do Firebase registada, implemente uma destas opções para evitar mais interrupções nos dados de lotes exportados.

Compreenda como a infraestrutura de exportação usa identificadores para escrever dados em tabelas BigQuery

Veja como as duas infraestruturas de exportação escrevem dados Crashlytics em tabelas de BigQuery lotes:

• Infraestrutura de exportação antiga: escreveu dados numa tabela com um nome baseado no ID do pacote ou no nome do pacote no binário da sua app.

• Nova infraestrutura de exportação: escreve dados numa tabela com um nome baseado no ID do pacote ou no nome do pacote definido para a sua app Firebase registada no projeto do Firebase.

Infelizmente, por vezes, o ID do pacote ou o nome do pacote no ficheiro binário da sua app não corresponde ao ID do pacote ou ao nome do pacote definido para a sua app Firebase registada no seu projeto do Firebase. Normalmente, isto acontece se alguém não tiver introduzido o identificador real durante o registo da app.

O que acontece se este problema não for corrigido antes da atualização?

Se os identificadores nestes dois locais não corresponderem, significa que ocorreu o seguinte:

• Os seus dados do Crashlytics são agora escritos numa tabela de lotes nova BigQuery, ou seja, uma nova tabela com um nome baseado no ID do pacote ou no nome do pacote definido para a sua app Firebase registada no projeto do Firebase.

• Qualquer tabela "antiga" existente com um nome baseado no identificador no binário da sua app já não tem dados escritos.

Cenários de exemplo de identificadores sem correspondência

Tenha em atenção que os nomes das tabelas de BigQuerylotes são anexados automaticamente com _IOS ou _ANDROID para indicar a plataforma da app.

Identificadores no binário da sua app	Identificadores definidos para as suas apps Firebase	Comportamento antigo	Comportamento após a atualização para a nova infraestrutura de exportação	Solução
foo	bar	Escreve numa tabela única com o nome do identificador no binário da app (foo)	Cria e, em seguida, escreve numa única tabela com o nome do identificador definido para a app Firebase (bar)	Implemente a opção 1 ou 2 descrita abaixo.
foo	bar, qux, etc.	Escreve numa tabela única com o nome do identificador no binário da app (foo)	Cria* e, em seguida, escreve em várias tabelas com os nomes dos identificadores definidos para as apps Firebase (bar, qux, etc.)	Implemente a Opção 2 descrita abaixo.
foo, baz, etc.	bar	Escreve em várias tabelas com nomes baseados nos vários identificadores no ficheiro binário da app (foo, baz, etc.)	Cria** e, em seguida, escreve os dados de cada app numa única tabela com o nome após o identificador definido para a app Firebase (bar)	Nenhuma das opções pode ser implementada. Pode continuar a diferenciar os dados de cada app na mesma tabela usando o bundle_identifier da app, que é exportado juntamente com os dados.

^{* Se o identificador no binário da sua app corresponder a um dos identificadores definidos para uma app Firebase, a nova infraestrutura de exportação não criou uma nova tabela para esse identificador. Em alternativa, continua a escrever dados para essa app específica. Todas as outras apps são escritas em novas tabelas.}

^{** Se um dos identificadores no binário da sua app corresponder ao conjunto de identificadores da app Firebase, a nova infraestrutura de exportação não cria uma nova tabela. Em vez disso, mantém essa tabela e começa a escrever dados para todas as apps na mesma.}

Opções para mitigar a interrupção

Importante: se tiver dúvidas ou não se sentir confortável em implementar uma destas opções, contacte o apoio técnico do Firebase.

• OPÇÃO 1:
  use a nova tabela criada pela nova infraestrutura de exportação. Copia os dados da tabela antiga para a nova tabela.

  1. Na consola Google Cloud, copie todos os dados da tabela antiga para a nova tabela criada durante a atualização da infraestrutura.

  2. Se tiver dependências a jusante que dependam da sua tabela de lotes, altere-as para usar a nova tabela.

  Nota: os novos dados não são escritos na tabela antiga. Os dados escritos anteriormente na tabela antiga não são eliminados.

• OPÇÃO 2:
  reconfigure para escrever novamente na tabela antiga. Tem de substituir algumas predefinições numa configuração do BigQuery para o conseguir.

  1. Na consola Firebase, localize e tome nota do ID da app do Firebase (por exemplo, 1:1234567890:ios:321abc456def7890) da app com o nome e o identificador da tabela de processamento em lote em desconformidade:
     aceda a Definições do projeto e, de seguida, aceda ao cartão As suas apps para ver todas as suas apps do Firebase e as respetivas informações.

  2. Na consola Google Cloud, altere a nova "configuração de transferência de dados" que foi criada pela atualização da infraestrutura para que os dados sejam escritos na tabela antiga:

     1. Aceda a BigQuery > Transferências de dados para ver a "configuração de transferência de dados".

     2. Selecione a configuração que tem a origem Firebase Crashlytics with Multi-Region Support.

     3. Clique em Editar no canto superior direito.

     4. Na secção Detalhes da origem de dados, encontre uma lista para gmp_app_id e uma lista para client_namespace.

        No BigQuery, o ID da app do Firebase é denominado gmp_app_id. Por predefinição, o valor client_namespace em BigQuery é o ID do pacote / nome do pacote exclusivo correspondente da app, mas vai substituir esta configuração predefinida.

        BigQuery usa o valor client_namespace para o nome da tabela de lotes na qual cada app do Firebase associada escreve.

     5. Encontre o gmp_app_id da app Firebase para a qual quer substituir as predefinições. Altere o respetivo valor client_namespace para o nome da tabela para a qual quer que a app Firebase escreva (normalmente, este é o nome da tabela antiga para a qual a app estava a escrever com a infraestrutura de exportação antiga).

        Nota: se estava anteriormente a escrever numa única tabela e agora tiver várias tabelas após a atualização, pode usar o mesmo client_namespace para cada gmp_app_id aplicável. BigQuery vai essencialmente unir todas as tabelas e escrever todos os dados de todas as apps do Firebase nessa tabela.

     6. Guarde a alteração de configuração.

  3. Agende um preenchimento para os dias em que a tabela antiga não tem dados.

  4. Quando o preenchimento estiver concluído, elimine a nova tabela que foi criada automaticamente pela nova infraestrutura de exportação.