Risoluzione dei problemi e domande frequenti su Crashlytics

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 nella console Firebase. Potresti anche notare una funzionalità denominata "varianti" in alcuni dei problemi. Ecco perché.

All'inizio del 2023, abbiamo implementato un motore di analisi migliorato per il raggruppamento degli eventi, nonché un design aggiornato e alcune funzionalità avanzate per i nuovi problemi (come le varianti). Dai un'occhiata al nostro recente post del blog per tutti i dettagli, ma continua a leggere per scoprire le novità principali.

Crashlytics analizza tutti gli eventi dell'app (ad esempio arresti anomali, errori non irreversibili 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, tra cui i frame nella traccia 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: ciascuna 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 diverse cause principali portano all'errore.

Ecco cosa noterai con questi miglioramenti:

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

• Meno problemi duplicati
  La modifica del numero di riga non genera un nuovo problema.

• Debug più semplice di problemi complessi con varie cause principali
  Usa 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, ne verifichiamo la corrispondenza con un problema esistente.

• Se non viene trovata alcuna 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 stiamo apportando al raggruppamento degli eventi. Se hai un feedback o riscontri problemi, comunicacelo inviando un report.

Mancata visualizzazione di metriche senza arresti anomali e/o avvisi di velocità

Se non visualizzi le metriche senza arresti anomali (come sessioni e utenti senza arresti anomali) e/o gli avvisi di velocità, assicurati di utilizzare 1.5 SDK di Crashlytics

Non vengono visualizzati i log dei breadcrumb

Se non visualizzi i log dei breadcrumb, ti consigliamo di controllare la configurazione dell'app per Google Analytics. Assicurati di soddisfare i seguenti requisiti:

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

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

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 dello 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 in visualizzazione alla 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 su un problema, ma non possono eliminarle o scriverne una.

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

Come vengono calcolati gli utenti senza arresti anomali?

Consulta Informazioni sulle 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 dello 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 in visualizzazione alla 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 su un problema, ma non possono eliminarle o scriverne una.

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

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 gli utenti che segnalano arresti anomali interferiscano durante la registrazione dei gestori delle eccezioni. Per risolvere il problema, disattiva la generazione di 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 vengono collocati automaticamente negli Stati Uniti, indipendentemente dalla posizione del progetto Firebase.

Che cos'è un problema rientrato?

Un problema ha subito una regressione quando l'hai chiuso in precedenza, ma Crashlytics riceve un nuovo report che indica che il problema si è ripresentato. Crashlytics riapre automaticamente questi problemi pregressi per consentirti di risolverli in modo 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 il 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 sapeva quando hai chiuso il problema (ovvero la versione aveva inviato un report sugli arresti anomali per qualsiasi arresto anomalo), Crashlytics non considererà il problema come pregresso. Il problema rimarrà chiuso.
   • Se il report proviene da una versione dell'app di cui Crashlytics non è a conoscenza quando hai chiuso il problema (il che significa che la versione non ha mai inviato alcun report sugli arresti anomali per alcun arresto anomalo), Crashlytics considera il problema pregresso e lo riapre.

Quando un problema regredisce, inviamo un avviso di rilevamento di regressione e aggiungiamo un segnale 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, "disattiva" il problema anziché chiuderlo.

Perché vedo problemi pregressi per versioni precedenti dell'app?

Se un report proviene da una versione precedente dell'app che non ha mai inviato report sugli arresti anomali quando hai chiuso il problema, Crashlytics lo considera rientrato e lo riapre.

Questa situazione può verificarsi nel seguente caso: hai corretto un bug e hai rilasciato una nuova versione della tua app, ma ci sono ancora utenti che utilizzano versioni precedenti senza la correzione del bug. Se, per caso, una di quelle versioni precedenti non aveva mai inviato report sugli arresti anomali quando hai chiuso il problema e gli utenti iniziavano a rilevare il bug, quei report sugli arresti anomali attiverebbero un problema pregresso.

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