Risoluzione dei problemi e domande frequenti su Crashlytics

Questa pagina fornisce assistenza per la risoluzione dei problemi e risposte alle domande frequenti sull'utilizzo di Crashlytics. Se non riesci a trovare quello che cerchi o hai bisogno di ulteriore aiuto, contatta l'assistenza Firebase.

Risoluzione dei problemi generali/domande frequenti

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

Potresti notare due formati diversi per i problemi elencati nella tabella Problemi della 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 alcune funzionalità avanzate per i nuovi problemi (come le varianti). Consulta il nostro recente post del blog 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 fatali e ANR) e crea gruppi di eventi chiamati problemi. Tutti gli eventi in 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, inclusi i frame nello stack trace, 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 che hanno 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 all'interno della riga del problema
  Ora è più facile comprendere e gestire i problemi nella tua app.

• Meno problemi duplicati
  Una modifica del numero di riga non comporta 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 in realtà un nuovo bug.

• Ricerca più potente
  Ogni problema contiene metadati più ricercabili, come il tipo di eccezione e il nome del pacchetto.

Ecco come vengono implementati questi miglioramenti:

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

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

Questo è il primo grande aggiornamento che stiamo apportando al raggruppamento degli eventi. Se hai feedback o riscontri problemi, comunicacelo inviando una segnalazione.

Non visualizzare i log breadcrumb

Se non visualizzi i log 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 Gestire 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 di utilizzare almeno la seguente versione dell'SDK Firebase per Google Analytics: iOS+: v6.3.1+ (v8.9.0+ per macOS e tvOS) | Android: v17.2.3+ (BoM v24.7.1+).

Non visualizzare gli avvisi di velocità

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

Non visualizzi le metriche senza arresti anomali (o visualizzi metriche inaffidabili)

Se non visualizzi le metriche relative agli arresti anomali (ad esempio utenti e sessioni senza arresti anomali) o se le metriche non sono 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 i report con consenso disattivando i report sugli arresti anomali automatici, le informazioni sugli arresti anomali possono essere inviate a Crashlytics solo dagli utenti che hanno attivato esplicitamente la raccolta dei dati. Pertanto, l'accuratezza delle metriche senza arresti anomali sarà influenzata, poiché Crashlytics dispone solo delle informazioni sugli arresti anomali di questi utenti che hanno attivato l'opzione (anziché di tutti gli utenti). Ciò significa che le metriche senza arresti anomali potrebbero essere meno affidabili e meno rappresentative della stabilità complessiva della tua app.

  • Se hai disattivato la raccolta automatica dei dati, puoi utilizzare sendUnsentReports per inviare a Crashlytics i report memorizzati nella cache sul dispositivo. L'utilizzo di questo metodo invierà i dati relativi agli arresti anomali a Crashlytics, ma non i dati relativi alle sessioni, il che fa sì che i grafici della console mostrino valori bassi o pari a zero per le metriche senza arresti anomali.

Come vengono calcolati gli utenti senza arresti anomali?

Consulta la sezione Comprendere le metriche senza arresti anomali.

Chi può visualizzare, scrivere ed eliminare le note relative a 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'email del suo Account Google. Questo indirizzo email è visibile, insieme alla nota, a tutti i membri del progetto con accesso alla visualizzazione della nota.

Di seguito è descritto l'accesso necessario 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 in un problema, ma non possono eliminarle o scriverne una.

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

Che cos'è un problema di regressione?

Un problema ha avuto una regressione quando lo hai chiuso in precedenza, ma Crashlytics riceve una nuova segnalazione 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 come Crashlytics classifica un problema come regressione:

1. Per la prima volta, Crashlytics riceve un report sugli arresti anomali relativo all'arresto anomalo "A". Crashlytics apre un problema corrispondente per l'arresto anomalo (problema "A").
2. Correggi rapidamente questo bug, chiudi il problema "A" e rilascia una nuova versione della tua app.
3. Crashlytics riceve un'altra segnalazione relativa al problema"A" dopo che lo hai chiuso.
   • Se il report proviene da una versione dell'app che Crashlytics era a conoscenza del problema quando l'hai chiuso (ovvero la versione aveva inviato un report sui blocchi per qualsiasi blocco), allora Crashlytics non considererà il problema come regresso. 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), allora Crashlytics considera il problema come regredito e lo riaprirà.

Nota:prima di febbraio 2022, Crashlytics classificava un problema come regressione quando si ripresentava in qualsiasi versione dell'app, anche per le versioni dell'app di cui eravamo a conoscenza quando hai chiuso il problema. Di conseguenza, Crashlytics a volte identifica in modo impreciso le regressioni. Ora utilizziamo la convenzione descritta sopra.

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

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

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

Questa situazione può verificarsi quando hai corretto un bug e rilasciato una nuova versione dell'app, ma alcuni utenti utilizzano ancora versioni precedenti senza la correzione del bug. Se, per caso, una di queste versioni precedenti non ha mai inviato report sugli arresti anomali quando hai chiuso il problema e gli utenti iniziano a riscontrare il bug, questi report sugli arresti anomali attiverebbero un problema di regressione.

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

Nota :prima di febbraio 2022, Crashlytics classificava un problema come regressione quando si ripresentava in qualsiasi versione dell'app, anche per le versioni dell'app di cui eravamo a conoscenza quando hai chiuso il problema. Di conseguenza, Crashlytics a volte identifica in modo impreciso le regressioni. Ora utilizziamo la convenzione descritta sopra.

Se noti molte regressioni identificate erroneamente prima di febbraio 2022, puoi richiuderle per evitare che si riaprano.

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 di arresti anomali interferiscano con la registrazione dei gestori di 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?

Dopo aver collegato Crashlytics a BigQuery, i nuovi set di dati che crei si trovano automaticamente negli Stati Uniti, indipendentemente dalla posizione del tuo progetto Firebase.

---

Supporto specifico per piattaforma

Le sezioni seguenti forniscono assistenza per la risoluzione dei problemi e domande frequenti specifiche per piattaforma: iOS+ | Android | Unity.

Supporto delle piattaforme Apple

I file dSYM sono mancanti/non vengono caricati

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

1. Assicurati che la fase di compilazione del progetto contenga lo script di esecuzione Crashlytics, che consente a Xcode di caricare i dSYM del progetto in fase di compilazione (leggi Inizializzazione di Crashlytics per istruzioni sull'aggiunta dello script). Dopo aver aggiornato il progetto, forza un arresto anomalo e verifica che l'arresto anomalo venga visualizzato nella dashboard 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 file dSYM e continui a visualizzare l'errore relativo ai file dSYM mancanti, è probabile che lo strumento di esecuzione dello script si blocchi durante il caricamento dei file dSYM. In questo caso, prova a eseguire le seguenti operazioni:

   • Assicurati di utilizzare l'ultima versione di Crashlytics.

   • Carica manualmente i file dSYM mancanti:

     • Opzione 1: utilizza l'opzione "Trascina e rilascia" basata su console nella scheda dSYM per caricare un archivio 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 i caricamenti non vanno a buon fine, contatta l'assistenza Firebase e assicurati di includere i log.

Arresti anomali con simbolizzazione scarsa

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

• Se i frame della libreria dell'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 elencati dSYM facoltativi come mancanti (per la versione dell'app interessata) nella scheda Crashlytics dSYM della console Firebase. In questo caso, segui il passaggio per la risoluzione dei problemi relativo all'"Avviso dSYM mancante" nelle Domande frequenti su dSYM mancanti/non caricati di 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 degli 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 breadcrumb).

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

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

---

Assistenza Android

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

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

Perché alcuni ANR non hanno i relativi BuildId?

Se in alcuni ANR mancano i BuildId, risolvi il problema nel seguente modo:

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

  Se mancano BuildId per Android 11 e alcuni errori 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 errori ANR, devi utilizzare le seguenti versioni:

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

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

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

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

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

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

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

  • Se conservi le versioni con e senza simboli di debug di una libreria, assicurati di puntare alla versione corretta nel codice.

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

Potrebbe esserci una mancata corrispondenza tra il conteggio degli errori ANR tra Google Play e Crashlytics. Ciò è previsto a causa della differenza nel meccanismo di raccolta e generazione di report sui dati ANR. Crashlytics segnala gli errori ANR al successivo avvio dell'app, mentre Android vitals invia i dati ANR dopo che si è verificato l'errore ANR.

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

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

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

Affinché Crashlytics possa generare problemi con l'estensione 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 alla versione R8, consulta questa documentazione.

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

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

A partire da metà dicembre 2021, Crashlytics è stato 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 di 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 (a seconda dei casi) 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 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 l'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 impedisce l'invio di report sugli arresti anomali. Per risolvere il problema:

1. Assicurati di utilizzare l'ultima versione di DexGuard 8.x. L'ultima versione contiene 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

Supporto specifico per Android NDK

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

Le toolchain LLVM e GNU hanno impostazioni predefinite e trattamenti distinti per il segmento di sola lettura dei file binari della tua app, che potrebbero generare stack trace incoerenti nella console Firebase. Per risolvere il 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 nella traccia dello stack (o se nessuno dei flag è pertinente alla tua toolchain), prova ad aggiungere quanto segue al processo di build invece:

-fno-omit-frame-pointer

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

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

Nota: per i file binari Android è necessaria la versione Linux del generatore di file di simboli Breakpad.

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

• 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 precedenti del plug-in

  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 come il 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.

---

Supporto di Unity

Visualizzazione di analisi dello stack senza simboli per le app per Android nella dashboard Crashlytics

Se utilizzi Unity IL2CPP e visualizzi stack trace non simbolici, prova a svolgere le seguenti operazioni:

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

2. Assicurati di aver configurato ed eseguito il comando Firebase CLI crashlytics:symbols:upload per generare e caricare il file di simboli.

   Devi eseguire questo comando CLI ogni volta che crei una build di rilascio o qualsiasi build per la quale vuoi visualizzare le analisi dello stack con simboli nella console Firebase. Scopri di più in Ottenere report sugli arresti anomali leggibili.

Crashlytics può essere utilizzato con app che utilizzano IL2CPP?

Sì, Crashlytics può visualizzare le tracce dello stack con simboli per le tue app che utilizzano IL2CPP. Questa funzionalità è disponibile per le app rilasciate sulle piattaforme Android o Apple. Ecco cosa devi 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 della piattaforma Apple: non sono necessarie azioni speciali. Per le app per piattaforma 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 di simboli.

     Devi eseguire questo comando CLI ogni volta che crei una build di rilascio o qualsiasi build per la quale vuoi visualizzare le analisi dello stack con simboli nella console Firebase. Scopri di più in Ottenere report sugli arresti anomali leggibili.

Segnalazione di eccezioni non rilevate come errori irreversibili

Crashlytics può segnalare le eccezioni non rilevate come errori irreversibili (a partire dalla versione 10.4.0 dell'SDK Unity). Le seguenti domande frequenti aiutano a spiegare la logica e le best practice per l'utilizzo di questa funzionalità.

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

Se segnali le eccezioni non rilevate come irreversibili, ottieni un'indicazione più realistica di quali eccezioni potrebbero rendere il gioco ingiocabile, anche se l'app continua a essere eseguita.

Tieni presente che se inizi a segnalare 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.

Importante: la segnalazione di eccezioni non rilevate come errori irreversibili non influisce su Android vitals. Gli errori fatali segnalati in Crashlytics sono visibili solo a te, in modo che tu possa scoprire e risolvere i problemi nelle tue app e nei tuoi giochi.

Quali eccezioni verranno segnalate come fatali?

Affinché Crashlytics possa segnalare 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 viene considerata non rilevata.

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

Quando inizi a ricevere report sulle eccezioni non rilevate come errori irreversibili, ecco alcune opzioni per la gestione di queste eccezioni non rilevate:

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

Rilevare e gestire 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 ripristino del programma a uno stato noto (un processo noto come gestione delle eccezioni).

La best practice consiste nell'intercettare 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 le eccezioni specifiche in modo appropriato.

Registrare le eccezioni in Unity o Crashlytics

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

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

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

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

• Opzione 2: caricamento su Crashlytics per report consolidati nella dashboard Crashlytics per le seguenti situazioni:

  • Se un'eccezione merita di essere registrata 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). Genera l'errore in modo non locale. Ciò significa che anche un Debug.LogException(exception) circostante con blocchi try-catch genera un'eccezione non rilevata.

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

• Per stampare l'eccezione nella console Unity.
• Per caricare l'eccezione su Crashlytics come evento irreversibile.
• Per generare l'eccezione, trattala come un'eccezione non rilevata e segnalala a Unity Cloud Diagnostics.

Tieni presente che se vuoi stampare un'eccezione rilevata nella console Unity e caricarla su Crashlytics come evento non irreversibile, segui questa procedura:

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