Risoluzione dei problemi e domande frequenti su Crashlytics

iOS+ Android Flutter Unity

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 apportiamo 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, 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 alla tua app. Questo SDK deve essere aggiunto in aggiunta all'SDK Crashlytics.

• Stai utilizzando le per tutti i prodotti che utilizzi nella tua app.

Non visualizzare gli avvisi di velocità

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

Non visualizzare le metriche senza arresti anomali (o visualizzare 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à interessata, poiché Crashlytics dispone solo delle informazioni sugli arresti anomali di questi utenti che hanno attivato la funzionalità (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 del progetto, Visualizzatore Firebase, Visualizzatore qualità, o Visualizzatore Crashlytics

Integrazioni

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 la segnalazione di 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 della piattaforma

Problemi regrediti

Che cos'è un problema di 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, 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 quando hai chiuso il problema (ovvero la versione aveva inviato un report sugli arresti anomali per qualsiasi arresto anomalo), 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 che conoscevamo 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, "silenzia" il problema anziché chiuderlo.

Perché vedo problemi di regressione 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 hai rilasciato una nuova versione dell'app, ma ci sono ancora utenti che utilizzano versioni precedenti senza la correzione del bug. Se, per caso, una di queste versioni precedenti non avesse mai inviato alcun report sugli arresti anomali quando hai chiuso il problema e questi 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 chiuderle di nuovo per evitare che si riaprano.