Risoluzione dei problemi di Crashlytics e domande frequenti

Visualizzazione di formati diversi (e talvolta "varianti") per alcuni problemi nella tabella Problemi

Potresti notare due formati diversi per i problemi elencati nella tabella Problemi nella console Firebase. Potresti anche notare una funzionalità chiamata "varianti" all'interno di alcuni problemi. Ecco perché.

All'inizio del 2023, abbiamo implementato un motore di analisi migliorato per il raggruppamento degli eventi, oltre a un design aggiornato e ad alcune funzionalità avanzate per i nuovi problemi (come le varianti). Dai un'occhiata al nostro recente blog post per tutti i dettagli, ma puoi leggere di seguito i punti salienti.

Crashlytics analizza tutti gli eventi della tua app (come arresti anomali, errori non irreversibili e ANR) e crea gruppi di eventi chiamati problemi. Tutti gli eventi di un problema hanno un punto di errore comune.

Per raggruppare gli eventi in questi problemi, il motore di analisi migliorato ora esamina molti aspetti dell'evento, tra cui i frame nell'analisi dello stack, il messaggio di eccezione, il codice di errore e altre caratteristiche della piattaforma o del tipo di errore.

Tuttavia, all'interno di questo gruppo di eventi, le analisi dello stack che portano all'errore potrebbero essere diverse. Un'analisi dello stack diversa potrebbe indicare una causa principale diversa. Per rappresentare questa possibile differenza all'interno di un problema, ora creiamo varianti all'interno dei problemi: ogni variante è un sottogruppo di eventi in un problema con lo stesso punto di errore e un'analisi dello stack simile. Con le varianti, puoi eseguire il debug delle analisi dello stack più comuni all'interno di un problema e determinare se cause principali diverse portano all'errore.

Ecco cosa potrai fare con questi miglioramenti:

• Metadati rinnovati visualizzati nella riga del problema
  Ora è più facile comprendere e classificare i problemi della tua app.

• Meno problemi duplicati
  Una modifica al numero di riga non genera un nuovo problema.

• Debug più semplice di problemi complessi con varie cause principali
  Utilizza le varianti per eseguire il debug delle analisi dello stack più comuni all'interno di un problema.

• Avvisi e indicatori più significativi
  Un nuovo problema rappresenta effettivamente un nuovo bug.

• Ricerca più efficace
  Ogni problema contiene più metadati disponibili per la ricerca, come il tipo di eccezione e il nome del pacchetto.

Ecco come verranno implementati questi miglioramenti:

• Quando riceviamo nuovi eventi dalla tua app, verifichiamo se corrispondono a un problema esistente.

• Se non esiste una corrispondenza, applicheremo automaticamente all'evento il nostro algoritmo di raggruppamento degli eventi più intelligente e creeremo un nuovo problema con il design dei metadati rinnovato.

Questo è il primo grande aggiornamento che apportiamo al nostro raggruppamento di eventi. Se hai feedback o riscontri problemi, comunicacelo inviando una segnalazione .

Non vedo i log dei breadcrumb

Se non vedi i log dei breadcrumb (iOS+ | Android | Flutter | Unity), ti consigliamo di controllare la configurazione dell'app per Google Analytics. Assicurati di soddisfare i seguenti requisiti:

• Hai attivato Google Analytics nel tuo progetto Firebase.

• Hai attivato la condivisione dei dati per Google Analytics. Scopri di più su questa impostazione in Gestisci le impostazioni di condivisione dei dati di Analytics.

• Hai aggiunto alla tua app l'SDK Firebase per Google Analytics: iOS+ | Android | Flutter | Unity.
  Questo SDK deve essere aggiunto in aggiunta all'SDK Crashlytics.

• Utilizzi le versioni più recenti dell'SDK Firebase per tutti i prodotti che utilizzi nella tua app (iOS+ | Android | Flutter | Unity).

  Per le piattaforme Apple e le app per Android, verifica in particolare che tu stia utilizzando almeno la seguente versione dell' SDK Firebase per Google Analytics: iOS+ - v6.3.1 o successive (v8.9.0 o successive per macOS e tvOS) | Android - v17.2.3 o successive (BoM v24.7.1 o successive).

Non vedo gli avvisi di velocità

Se non vedi gli avvisi di velocità, assicurati di utilizzare

Le metriche relative alle sessioni senza arresti anomali non vengono visualizzate (o vengono visualizzate metriche non affidabili)

Se non vedi le metriche relative alle sessioni senza arresti anomali (come utenti e sessioni senza arresti anomali) o se vedi metriche non affidabili, controlla quanto segue:

• Assicurati di utilizzare

• Assicurati che le impostazioni di raccolta dei dati non influiscano sulla qualità delle metriche senza arresti anomali:

  • Se attivi la generazione di report con attivazione disattivando Crash Reporting automatico, le informazioni sugli arresti anomali possono essere inviate a Crashlytics solo dagli utenti che hanno attivato esplicitamente la raccolta dei dati. Di conseguenza, l'accuratezza delle metriche relative alle sessioni senza arresti anomali sarà influenzata, poiché Crashlytics dispone solo delle informazioni sugli arresti anomali di questi utenti che hanno eseguito l'opt-in (anziché di tutti i tuoi utenti). Ciò significa che le metriche senza arresti anomali potrebbero essere meno affidabili e meno indicative della stabilità complessiva della tua app.

  • Se la raccolta dei dati automatica è disattivata, puoi utilizzare sendUnsentReports per inviare report memorizzati nella cache sul dispositivo a Crashlytics. Se utilizzi questo metodo, i dati sugli arresti anomali verranno inviati a Crashlytics, ma non i dati sulle sessioni, il che fa sì che i grafici della console mostrino valori bassi o pari a zero per le metriche relative alle sessioni senza arresti anomali.

Come vengono calcolati gli utenti senza arresti anomali?

Consulta Informazioni sulle metriche senza arresti anomali.

Chi può visualizzare, scrivere ed eliminare le note su un problema?

Le note consentono ai membri del progetto di commentare problemi specifici con domande, aggiornamenti di stato e così via.

Quando un membro del progetto pubblica una nota, questa viene etichettata con l'indirizzo email del suo Account Google. Questo indirizzo email è visibile, insieme alla nota, a tutti i membri del progetto con accesso per visualizzare la nota.

Di seguito sono descritti gli accessi necessari per visualizzare, scrivere ed eliminare le note:

• I membri del progetto con uno dei seguenti ruoli possono visualizzare ed eliminare le note esistenti e scrivere nuove note su un problema.

  • Proprietario o Editor del progetto, Amministratore Firebase, Amministratore qualità o Amministratore Crashlytics

• I membri del progetto con uno dei seguenti ruoli possono visualizzare le note pubblicate su un problema, ma non possono eliminarle o scriverle.

  • Visualizzatore del progetto, Visualizzatore Firebase, Visualizzatore qualità o Visualizzatore Crashlytics

Che cos'è un problema con regressione?

Un problema ha subito una regressione quando lo hai chiuso in precedenza, ma Crashlytics riceve una nuova segnalazione che indica che il problema si è ripresentato. Crashlytics riapre automaticamente questi problemi di regressione in modo che tu possa risolverli nel modo più appropriato per la tua app.

Ecco uno scenario di esempio che spiega in che modo Crashlytics classifica un problema come regressione:

1. Per la prima volta in assoluto, Crashlytics riceve un report sugli arresti anomali relativo all'arresto anomalo "A". Crashlytics apre un problema corrispondente per l'arresto anomalo (problema "A").
2. Risolvi rapidamente questo bug, chiudi il problema "A" e rilasci una nuova versione della tua app.
3. Crashlytics riceve un'altra segnalazione relativa al problema"A" dopo che lo hai chiuso.
   • Se la segnalazione proviene da una versione dell'app di cui Crashlytics era a conoscenza quando hai chiuso il problema (ovvero la versione aveva inviato una segnalazione di arresto anomalo per qualsiasi arresto anomalo), Crashlytics non considererà il problema come una regressione. Il problema rimarrà chiuso.
   • Se la segnalazione proviene da una versione dell'app che Crashlytics non conosceva quando hai chiuso il problema (ovvero la versione non aveva mai inviato alcuna segnalazione di arresto anomalo per nessun arresto anomalo), Crashlytics considera il problema come una regressione e lo riaprirà.

Quando un problema si ripresenta, inviamo un avviso di rilevamento della regressione e aggiungiamo un indicatore di regressione al problema per informarti che Crashlytics ha riaperto il problema. Se non vuoi che un problema venga riaperto a causa del nostro algoritmo di regressione, "disattivalo" anziché chiuderlo.

Perché vedo problemi con regressione per le versioni precedenti dell'app?

Se un report proviene da una versione precedente dell'app che non aveva mai inviato report sugli arresti anomali quando hai chiuso il problema, Crashlytics considera il problema come una regressione e lo riaprirà.

Questa situazione può verificarsi nel seguente caso: hai corretto un bug e rilasciato una nuova versione della tua app, ma alcuni utenti utilizzano ancora versioni precedenti senza la correzione di bug. Se, per caso, una di queste versioni precedenti non aveva mai inviato report sugli arresti anomali quando hai chiuso il problema e gli utenti iniziano a riscontrare il bug, i report sugli arresti anomali attiveranno un problema di regressione.

Se non vuoi che un problema venga riaperto a causa del nostro algoritmo di regressione, "disattivalo" anziché chiuderlo.

I file dSYM sono mancanti o non vengono caricati

Per caricare i dSYM del progetto e ottenere un output dettagliato, controlla quanto segue:

1. Assicurati che la fase di build del progetto contenga lo script di esecuzione Crashlytics, che consente a Xcode di caricare i dSYM del progetto al momento della build (leggi Inizializzazione di Crashlytics per istruzioni su come aggiungere lo script). Dopo aver aggiornato il progetto, forza un arresto anomalo e verifica che venga visualizzato nella dashboard di Crashlytics.

2. Se nella console Firebase viene visualizzato l'avviso"dSYM mancante", controlla Xcode per assicurarti che produca correttamente i dSYM per la build.

3. Se Xcode produce correttamente i dSYM e continui a visualizzare dSYM mancanti, è probabile che lo strumento di script di esecuzione si blocchi durante il caricamento dei dSYM. In questo caso, prova a eseguire nell'ordine tutte le seguenti operazioni:

   • Assicurati di utilizzare l'ultima versione di Crashlytics.

   • Carica manualmente i file dSYM mancanti:

     • Opzione 1: utilizza l'opzione "Trascina" basata sulla console nella scheda dSYM per caricare un file ZIP contenente i file dSYM mancanti.
     • Opzione 2: utilizza lo script upload-symbols per caricare i file dSYM mancanti per gli UUID forniti nella scheda dSYM.

4. Se continui a visualizzare dSYM mancanti o se i caricamenti continuano a non riuscire, contatta l'assistenza Firebase e assicurati di includere i log.

Gli arresti anomali sono simbolizzati in modo inadeguato

Se le analisi dello stack sembrano essere simbolizzate in modo errato, controlla quanto segue:

• Se i frame della libreria della tua app non contengono riferimenti al codice dell'app, assicurati che -fomit-frame-pointer non sia impostato come flag di compilazione.

• Se vedi diversi frame (Missing) per la libreria della tua app, controlla se sono presenti dSYM facoltativi elencati come mancanti (per la versione dell'app interessata) nella Crashlytics scheda dSYM della console Firebase. In questo caso, segui il passaggio per la risoluzione dei problemi "Avviso dSYM mancante" nelle Domande frequenti sui dSYM mancanti/non caricati in questa pagina. Tieni presente che il caricamento di questi dSYM non simbolizzerà gli arresti anomali che si sono già verificati, ma contribuirà a garantire la simbolizzazione per gli arresti anomali futuri.

Posso utilizzare Crashlytics per macOS o tvOS?

Sì, puoi implementare Crashlytics nei progetti macOS e tvOS. Assicurati di includere la versione 8.9.0 o successive dell'SDK Firebase per Google Analytics in modo che gli arresti anomali abbiano accesso alle metriche raccolte da Google Analytics (utenti senza arresti anomali, ultima release, avvisi di velocità e log dei breadcrumb).

Posso utilizzare Crashlytics in un progetto Firebase con più app su piattaforme Apple diverse?

Ora puoi segnalare gli arresti anomali per più app in un unico progetto Firebase, anche se le app sono create per piattaforme Apple diverse (ad esempio iOS, tvOS e Mac Catalyst). In precedenza, dovevi separare le app in singoli progetti Firebase se contenevano lo stesso ID pacchetto.

Perché gli ANR vengono segnalati solo per Android 11 e versioni successive?

Crashlytics supporta i report ANR per le app per Android da dispositivi con Android 11 e versioni successive. L'API sottostante che utilizziamo per raccogliere gli ANR (getHistoricalProcessExitReasons) è più affidabile degli approcci basati su SIGQUIT o watchdog. Questa API è disponibile solo sui dispositivi Android 11 e versioni successive.

Perché in alcuni ANR mancano i BuildId?

Se alcuni dei tuoi ANR non hanno i BuildId, procedi come segue per risolvere il problema:

• Assicurati di utilizzare una versione aggiornata dell'SDK Android Crashlytics e del plug-in Gradle Crashlytics.

  Se mancano i BuildId per Android 11 e alcuni ANR di Android 12, è probabile che tu stia utilizzando un SDK, un plug-in Gradle o entrambi obsoleti. Per raccogliere correttamente i BuildId per questi ANR, devi utilizzare le seguenti versioni:

  • Crashlytics SDK Android v18.3.5 o versioni successive (Firebase BoM v31.2.2 o versioni successive)
  • Crashlytics Plug-in Gradle v2.9.4 e versioni successive

• Controlla se stai utilizzando una posizione non standard per le librerie condivise.

  Se mancano solo iBuildIdper le librerie condivise della tua app, è probabile che tu non stia utilizzando la posizione predefinita standard per le librerie condivise. In questo caso, Crashlytics potrebbe non essere in grado di individuare i BuildId associati. Ti consigliamo di valutare l'utilizzo della posizione standard per le librerie condivise.

• Assicurati di non rimuovere i BuildId durante il processo di build.

  Tieni presente che i seguenti suggerimenti per la risoluzione dei problemi si applicano sia agli ANR sia agli arresti anomali nativi.

  • Controlla se i BuildId esistono eseguendo readelf -n sui tuoi binari. Se i BuildId non sono presenti, aggiungi -Wl,--build-id ai flag del tuo sistema di build.

  • Verifica di non rimuovere involontariamente i BuildId nel tentativo di ridurre le dimensioni dell'APK.

  • Se conservi le versioni con e senza stripping di una libreria, assicurati di fare riferimento alla versione corretta nel codice.

Differenze tra i report ANR nella dashboard Crashlytics e in Google Play Console

Potrebbe esserci una discrepanza tra il numero di ANR tra Google Play e Crashlytics. Si tratta di un comportamento previsto a causa della differenza nel meccanismo di raccolta e generazione di report dei dati ANR. Crashlytics segnala gli ANR al successivo avvio dell'app, mentre Android vitals invia i dati ANR dopo che si verifica l'ANR.

Inoltre, Crashlytics mostra solo gli ANR che si verificano sui dispositivi con Android 11 e versioni successive, mentre Google Play mostra gli ANR dei dispositivi con Google Play Services e con il consenso alla raccolta dei dati accettato.

Perché vedo arresti anomali da file .kt etichettati come problemi .java?

Quando un'app utilizza un offuscatore che non espone l'estensione del file, Crashlytics genera ogni numero con un'estensione del file .java per impostazione predefinita.

Affinché Crashlytics possa generare problemi con l'estensione del file corretta, assicurati che la tua app utilizzi la seguente configurazione:

• Utilizza Android Gradle 4.2.0 o versioni successive
• Utilizza R8 con l'offuscamento attivato. Per aggiornare l'app a R8, segui questa documentazione.

Tieni presente che, dopo l'aggiornamento alla configurazione descritta sopra, potresti iniziare a visualizzare nuovi problemi di .kt che sono duplicati di problemi di .java esistenti. Consulta le domande frequenti per saperne di più su questa circostanza.

Perché vedo problemi di .kt che sono duplicati di problemi di .java esistenti?

A partire da metà dicembre 2021, Crashlytics ha migliorato il supporto per le applicazioni che utilizzano Kotlin.

Fino a poco tempo fa, gli offuscatori disponibili non esponevano l'estensione del file, quindi Crashlytics generava ogni problema con un'estensione del file .java per impostazione predefinita. Tuttavia, a partire da Android Gradle 4.2.0, R8 supporta le estensioni dei file.

Con questo aggiornamento, Crashlytics ora può determinare se ogni classe utilizzata nell'app è scritta in Kotlin e includere il nome file corretto nella firma del problema. Gli arresti anomali ora vengono attribuiti correttamente ai file .kt (se appropriato) se la tua app ha la seguente configurazione:

• La tua app utilizza Android Gradle 4.2.0 o versioni successive.
• La tua app utilizza R8 con l'offuscamento attivato.

Poiché i nuovi arresti anomali ora includono l'estensione del file corretta nelle firme dei problemi, potresti visualizzare nuovi problemi .kt che in realtà sono solo duplicati di problemi esistenti con l'etichetta .java. Nella Console Firebase, cerchiamo di identificare e comunicarti se un nuovo problema .kt è un possibile duplicato di un problema esistente con etichetta .java.

Nessun arresto anomalo con Dexguard

Se visualizzi la seguente eccezione, è probabile che tu stia utilizzando una versione di DexGuard incompatibile con l'SDK Firebase Crashlytics:

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

Questa eccezione non causa l'arresto anomalo dell'app, ma le impedisce di inviare report sugli arresti anomali. Per risolvere il problema:

1. Assicurati di utilizzare l'ultima versione di DexGuard 8.x. L'ultima versione contiene le regole richieste dall'SDK Firebase Crashlytics.

2. Se non vuoi modificare la versione di DexGuard, prova ad aggiungere la seguente riga alle regole di offuscamento (nel file di configurazione di DexGuard):

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

Come eseguire l'upgrade alla versione 3 del plug-in Gradle Crashlytics?

L'ultima release del plug-in Gradle Crashlytics è una versione principale (v3.0.0) e modernizza l'SDK eliminando il supporto per le versioni precedenti di Gradle e del plug-in Android per Gradle. Inoltre, le modifiche apportate in questa release risolvono i problemi relativi ad AGP v8.1+ e migliorano il supporto per le app native e le build personalizzate.

Requisiti minimi

Il plug-in Gradle Crashlytics v3 ha i seguenti requisiti minimi:

• Plug-in Android per Gradle 8.1+
  Esegui l'upgrade di questo plug-in utilizzando l'assistente per l'upgrade del plug-in Android per Gradle nell'ultima versione di Android Studio.

• google-servicesPlug-in Gradle 4.4.1 e versioni successive
  di Firebase Esegui l'upgrade di questo plug-in specificando l'ultima versione nel file di build Gradle del progetto, in questo modo:

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

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

Modifiche all'estensione Crashlytics

Con la versione 3 del plug-in Gradle Crashlytics, l'estensione Crashlytics presenta le seguenti modifiche che provocano errori:

• L'estensione è stata rimossa dal blocco Android defaultConfig. Devi invece configurare ogni variante.

• Rimosso il campo deprecato mappingFile. Ora il file di mappatura unito viene fornito automaticamente.

• Rimosso il campo deprecato strippedNativeLibsDir. Devi invece utilizzare unstrippedNativeLibsDir per tutte le librerie native.

• Il campo unstrippedNativeLibsDir è stato modificato in cumulativo.

  Visualizza un esempio con più directory

  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")
        }
      }
    }
  }

  L'attività uploadCrashlyticsSymbolFilesBasicRelease caricherà solo i simboli in MY/NATIVE/LIBS, mentre uploadCrashlyticsSymbolFilesFeatureXRelease caricherà i simboli sia in MY/NATIVE/LIBS sia in MY/FEATURE_X/LIBS.

• Il campo di chiusura symbolGenerator è stato sostituito con due nuovi campi di primo livello:

  • symbolGeneratorType, una stringa di "breakpad" (predefinita) o "csym".
  • breakpadBinary, un file di un override binario dump_syms locale.

Esempio di come eseguire l'upgrade dell'estensione

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

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGeneratorType = "breakpad"
              breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGenerator {
                breakpad {
                  binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              }
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

Differenze tra le analisi dello stack NDK nella dashboard Crashlytics e in logcat

Le toolchain LLVM e GNU hanno valori predefiniti e trattamenti distinti per il segmento di sola lettura dei file binari della tua app, il che potrebbe generare analisi dello stack incoerenti nella console Firebase. Per mitigare questo problema, aggiungi i seguenti flag del linker al processo di build:

• Se utilizzi il linker lld della toolchain LLVM, aggiungi:

  -Wl,--no-rosegment

• Se utilizzi il linker ld.gold della toolchain GNU, aggiungi:

  -Wl,--rosegment

Se continui a riscontrare incoerenze nell'analisi dello stack (o se nessuno dei flag è pertinente alla tua toolchain), prova ad aggiungere quanto segue al processo di build:

-fno-omit-frame-pointer

Come faccio a utilizzare il mio file binario del generatore di file dei simboli Breakpad per NDK?

Il plug-in Crashlytics include un generatore di file di simboli Breakpad personalizzato. Se preferisci utilizzare il tuo file binario per generare i file dei simboli Breakpad (ad esempio, se preferisci creare tutti gli eseguibili nativi nella catena di build dal codice sorgente), utilizza la proprietà di estensione facoltativa symbolGeneratorBinary per specificare il percorso dell'eseguibile.

Puoi specificare il percorso del file binario del generatore di file dei simboli Breakpad in uno dei seguenti modi:

• Opzione 1: specifica il percorso tramite l'estensione firebaseCrashlytics nel file build.gradle

  Aggiungi quanto segue al file build.gradle.kts a livello di app:

  Plug-in Gradle v3.0.0+

  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")
        }
      }
    }
  }

  versioni del plug-in precedenti

  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")
            }
          }
        }
     }
  }

• Opzione 2: specifica il percorso tramite una riga di proprietà nel file delle proprietà di Gradle

  Puoi utilizzare la proprietà com.google.firebase.crashlytics.breakpadBinary per specificare il percorso dell'eseguibile.

  Puoi aggiornare manualmente il file delle proprietà di Gradle o aggiornarlo tramite la riga di comando. Ad esempio, per specificare il percorso tramite la riga di comando, utilizza un comando simile al seguente:

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

Crashlytics supporta armeabi?

L'NDK Firebase Crashlytics non supporta ARMv5 (armeabi). Il supporto di questa ABI è stato rimosso a partire da NDK r17.

Analisi dello stack non simbolizzate per le app per Android nella dashboard Crashlytics

Se utilizzi Unity IL2CPP e visualizzi analisi dello stack non simbolizzate, prova a seguire questi passaggi:

1. Assicurati di utilizzare la versione 8.6.1 o successive dell'SDK Unity Crashlytics.

2. Assicurati di aver configurato ed eseguito il comando crashlytics:symbols:upload dell'interfaccia a riga di comando Firebase per generare e caricare il file dei simboli.

   Devi eseguire questo comando della CLI ogni volta che crei una build di release o qualsiasi build per cui vuoi visualizzare analisi dello stack con simboli nella console Firebase. Scopri di più in Ricevi report sugli arresti anomali leggibili.

Crashlytics può essere utilizzato con le app che usano IL2CPP?

Sì, Crashlytics può mostrare analisi dello stack con simboli per le tue app che utilizzano IL2CPP. Questa funzionalità è disponibile per le app rilasciate su piattaforme Android o Apple. Ecco cosa fare:

1. Assicurati di utilizzare la versione 8.6.0 o successive dell'SDK Unity Crashlytics.

2. Completa le attività necessarie per la tua piattaforma:

   • Per le app per piattaforme Apple: non sono necessarie azioni speciali. Per le app per piattaforme Apple, il plug-in Firebase Unity Editor configura automaticamente il progetto Xcode per caricare i simboli.

   • Per le app per Android: assicurati di aver configurato ed eseguito il comando Firebase CLI crashlytics:symbols:upload per generare e caricare il file dei simboli.

     Devi eseguire questo comando della CLI ogni volta che crei una build di release o qualsiasi build per cui vuoi visualizzare analisi dello stack con simboli nella console Firebase. Scopri di più in Ricevi report sugli arresti anomali leggibili.

Perché un'app dovrebbe segnalare le eccezioni non rilevate come errori irreversibili?

Segnalando le eccezioni non rilevate come irreversibili, ottieni un'indicazione più realistica di quali eccezioni potrebbero rendere il gioco non giocabile, anche se l'app continua a funzionare.

Tieni presente che se inizi a segnalare gli errori irreversibili, la percentuale di utenti senza arresti anomali (CFU) probabilmente diminuirà, ma la metrica CFU sarà più rappresentativa delle esperienze degli utenti finali con la tua app.

Quali eccezioni verranno segnalate come irreversibili?

Affinché Crashlytics segnali un'eccezione non rilevata come irreversibile, devono essere soddisfatte entrambe le seguenti condizioni:

• Durante l'inizializzazione nell'app, la proprietà ReportUncaughtExceptionsAsFatal deve essere impostata su true.

• La tua app (o una libreria inclusa) genera un'eccezione che non viene rilevata. Un'eccezione creata, ma non generata, non è considerata non rilevata.

Dopo aver attivato la segnalazione delle eccezioni non rilevate come eventi irreversibili, ora ho molti nuovi eventi irreversibili. Come faccio a gestire correttamente queste eccezioni?

Quando inizi a ricevere report sulle eccezioni non rilevate come errori irreversibili, ecco alcune opzioni per gestirle:

• Valuta come iniziare a rilevare e gestire queste eccezioni non rilevate.
• Valuta diverse opzioni per registrare le eccezioni nella console di debug di Unity e in Crashlytics.

Intercetta e gestisci le eccezioni generate

Le eccezioni vengono create e generate per riflettere stati imprevisti o eccezionali. La risoluzione dei problemi indicati da un'eccezione generata comporta il ritorno del programma a uno stato noto (un processo noto come gestione delle eccezioni).

La best practice consiste nel rilevare e gestire tutte le eccezioni previste, a meno che il programma non possa essere riportato a uno stato noto.

Per controllare quali tipi di eccezioni vengono rilevati e gestiti da quale codice, inserisci il codice che potrebbe generare un'eccezione in un blocco try-catch. Assicurati che le condizioni nelle istruzioni catch siano il più specifiche possibile per gestire in modo appropriato le eccezioni specifiche.

Registra le eccezioni in Unity o Crashlytics

Esistono diversi modi per registrare le eccezioni in Unity o Crashlytics per facilitare il debug del problema.

Quando utilizzi Crashlytics, ecco le due opzioni più comuni e consigliate:

• Opzione 1: stampa nella console Unity, ma non inviare report a Crashlytics, durante lo sviluppo o la risoluzione dei problemi

  • Stampa sulla console Unity utilizzando Debug.Log(exception), Debug.LogWarning(exception) e Debug.LogError(exception), che stampano i contenuti dell'eccezione sulla console Unity e non generano nuovamente l'eccezione.

• Opzione 2: carica i dati su Crashlytics per generare report consolidati nella dashboard di Crashlytics per le seguenti situazioni:

  • Se vale la pena registrare un'eccezione per eseguire il debug di un possibile evento Crashlytics successivo, utilizza Crashlytics.Log(exception.ToString()).
  • Se un'eccezione deve comunque essere segnalata a Crashlytics nonostante sia stata rilevata e gestita, utilizza Crashlytics.LogException(exception) per registrarla come evento non irreversibile.

Tuttavia, se vuoi segnalare manualmente un evento irreversibile a Unity Cloud Diagnostics, puoi utilizzare Debug.LogException. Questa opzione stampa l'eccezione nella console Unity come l'Opzione 1, ma genera anche l'eccezione (indipendentemente dal fatto che sia stata generata o rilevata o meno). Genera l'errore non localmente. Ciò significa che anche un Debug.LogException(exception) circostante con blocchi try-catch genera comunque un'eccezione non rilevata.

Pertanto, chiama Debug.LogException solo se vuoi eseguire tutte le seguenti operazioni:

• Per stampare l'eccezione nella console Unity.
• Per caricare l'eccezione su Crashlytics come evento irreversibile.
• Per generare l'eccezione, fai in modo che venga trattata come un'eccezione non rilevata e che venga segnalata a Unity Cloud Diagnostics.

Tieni presente che se vuoi stampare un'eccezione rilevata nella console Unity e caricarla su Crashlytics come evento non irreversibile, devi procedere nel seguente modo:

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
    //
}

L'app utilizza anche l'SDK Google Mobile Ads, ma non si verificano arresti anomali

Se il tuo progetto utilizza Crashlytics insieme all'SDK Google Mobile Ads, è probabile che i reporter degli arresti anomali interferiscano durante la registrazione dei gestori delle eccezioni. Per risolvere il problema, disattiva i report sugli arresti anomali nell'SDK Mobile Ads chiamando disableSDKCrashReporting.

Dove si trova il mio set di dati BigQuery?

Firebase esporta i dati nella località del set di dati selezionata durante la configurazione dell'esportazione dei dati in BigQuery.

• Questa località si applica sia al set di dati Crashlytics sia al set di dati delle sessioni Firebase (se i dati delle sessioni sono abilitati per l'esportazione).

• Questa località è applicabile solo ai dati esportati in BigQuery e non influisce sulla località dei dati archiviati per l'utilizzo nella dashboard Crashlytics della console Firebase o in Android Studio.

• Dopo la creazione di un set di dati, la sua località non può essere modificata, ma puoi copiarlo in un'altra località o spostarlo (ricrearlo) manualmente in un'altra località. Per saperne di più, consulta Modifica la località per le esportazioni esistenti.

Problemi dopo l'upgrade alla nuova infrastruttura di esportazione per BigQuery?

A metà ottobre 2024, Crashlytics ha lanciato una nuova infrastruttura per l'esportazione in batch dei dati di Crashlytics in BigQuery.

Il 2 marzo 2026 è stato eseguito l'upgrade automatico di tutti i progetti Firebase alla nuova infrastruttura di esportazione batch.

Differenze importanti tra la vecchia e la nuova infrastruttura di esportazione

• La nuova infrastruttura supporta Crashlytics località dei set di dati al di fuori degli Stati Uniti.

  • Esportazione attivata prima di metà ottobre 2024 e upgrade alla nuova infrastruttura di esportazione: ora puoi facoltativamente modificare la località per l'esportazione dei dati.

  • Esportazione attivata a metà ottobre 2024 o in un secondo momento: durante la configurazione ti è stato chiesto di selezionare una località per l'esportazione dei dati.

• La nuova infrastruttura non supporta i backfill dei dati precedenti all'attivazione dell'esportazione.

  • La vecchia infrastruttura supportava il backfill fino a 30 giorni prima della data di attivazione dell'esportazione.

  • La nuova infrastruttura supporta i backfill fino agli ultimi 30 giorni o fino alla data più recente in cui hai attivato l'esportazione in BigQuery (a seconda di quale sia la più recente).

• La nuova infrastruttura assegna un nome alle tabelle batch BigQuery utilizzando gli identificatori impostati per le tue app Firebase nel progetto Firebase.

  • La vecchia infrastruttura scriveva i dati in tabelle batch con nomi basati sugli ID pacchetto o sui nomi dei pacchetti nel file binario dell'app.

  • La nuova infrastruttura scrive i dati in tabelle batch con nomi basati sugli ID pacchetto o sui nomi dei pacchetti impostati per le tue app Firebase registrate nel tuo progetto Firebase.

Se il nome della tabella batch legacy non corrispondeva all'identificatore dell'app Firebase

Se il nome della tabella batch precedente non corrispondeva all'ID pacchetto o al nome del pacchetto impostato per l'app Firebase registrata, implementa una di queste opzioni per evitare ulteriori interruzioni dei dati batch esportati.

Scopri come l'infrastruttura di esportazione utilizza gli identificatori per scrivere i dati nelle tabelle BigQuery

Ecco come le due infrastrutture di esportazione scrivono i dati di Crashlytics nelle tabelle batch di BigQuery:

• Infrastruttura di esportazione precedente: i dati venivano scritti in una tabella con un nome basato sull'ID pacchetto o sul nome del pacchetto nel file binario dell'app.

• Nuova infrastruttura di esportazione: scrive i dati in una tabella con un nome basato sull'ID pacchetto o sul nome del pacchetto impostato per l'app Firebase registrata nel progetto Firebase.

Purtroppo, a volte l'ID pacchetto o il nome del pacchetto nel file binario dell'app non corrisponde all'ID pacchetto o al nome del pacchetto impostato per l'app Firebase registrata nel progetto Firebase. In genere, questo accade se un utente non ha inserito l'identificatore effettivo durante la registrazione dell'app.

Che cosa succede se il problema non è stato risolto prima dell'upgrade?

Se gli identificatori in queste due posizioni non corrispondono, si è verificato quanto segue:

• I dati di Crashlytics ora vengono scritti in una nuova tabella batch BigQuery, ovvero una nuova tabella con un nome basato sull'ID pacchetto o sul nome del pacchetto impostato per l'app Firebase registrata nel tuo progetto Firebase.

• I dati non vengono più scritti in nessuna tabella "legacy" esistente con un nome basato sull'identificatore nel file binario dell'app.

Scenari di esempio di identificatori non corrispondenti

Tieni presente che ai nomi delle tabelle batch BigQuery vengono aggiunti automaticamente _IOS o _ANDROID per indicare la piattaforma dell'app.

^{* Se l'identificatore nel file binario della tua app corrispondeva a uno degli identificatori impostati per un'app Firebase, la nuova infrastruttura di esportazione non ha creato una nuova tabella per quell'identificatore. Continuerà invece a scrivere i dati per l'app specifica. Tutte le altre app verranno scritte in nuove tabelle.}

^{** Se uno degli identificatori nel file binario della tua app corrispondeva all'identificatore impostato per l'app Firebase, la nuova infrastruttura di esportazione non ha creato una nuova tabella. Invece, manterrà la tabella e inizierà a scrivere i dati di tutte le app al suo interno.}

Opzioni per mitigare l'interruzione

• OPZIONE 1:
  Utilizza la nuova tabella creata dalla nuova infrastruttura di esportazione. Copierai i dati dalla tabella precedente alla nuova tabella.

  1. Nella console Google Cloud, copia tutti i dati dalla tabella precedente alla nuova tabella creata durante l'upgrade dell'infrastruttura.

  2. Se hai dipendenze downstream che dipendono dalla tabella batch, modificale in modo che utilizzino la nuova tabella.

• OPZIONE 2:
  Riconfigura per scrivere di nuovo nella tabella precedente. Per farlo, dovrai eseguire l'override di alcuni valori predefiniti in una configurazione BigQuery.

  1. Nella console Firebase, individua e prendi nota dell'ID app Firebase (ad esempio 1:1234567890:ios:321abc456def7890) dell'app con il nome e l'identificatore della tabella batch non corrispondenti:
     Vai alle settings Impostazioni progetto, quindi vai alla scheda Le tue app per visualizzare tutte le tue app Firebase e le relative informazioni.

  2. Nella console Google Cloud, modifica la nuova "configurazione del trasferimento di dati" creata dall'upgrade dell'infrastruttura in modo che i dati vengano scritti nella tabella legacy:

     1. Vai a BigQuery > Trasferimenti di dati per visualizzare la "configurazione del trasferimento di dati".

     2. Seleziona la configurazione con l'origine Firebase Crashlytics with Multi-Region Support.

     3. Fai clic su Modifica nell'angolo in alto a destra.

     4. Nella sezione Dettagli origine dati, individua un elenco per gmp_app_id e un elenco per client_namespace.

        In BigQuery, l'ID app Firebase è chiamato gmp_app_id. Per impostazione predefinita, il valore client_namespace in BigQuery è l'ID pacchetto / nome pacchetto univoco corrispondente dell'app, ma eseguirai l'override di questa configurazione predefinita.

        BigQuery utilizza il valore client_namespace per il nome della tabella batch in cui scrive ogni app Firebase collegata.

     5. Trova il gmp_app_id dell'app Firebase per cui vuoi eseguire l'override delle impostazioni predefinite. Modifica il valore client_namespace con il nome della tabella in cui vuoi che l'app Firebase scriva (di solito si tratta del nome della tabella precedente in cui l'app scriveva con l'infrastruttura di esportazione precedente).

     6. Salva la modifica della configurazione.

  3. Pianifica un backfill per i giorni in cui mancano i dati nella tabella legacy.

  4. Al termine del backfill, elimina la nuova tabella creata automaticamente dalla nuova infrastruttura di esportazione.