Risoluzione dei problemi e domande frequenti su Crashlytics

iOS e versioni successive Android Flusso Unità

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

Domande frequenti/risoluzione dei problemi generali

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à chiamata "varianti" in alcuni dei tuoi 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 della tua app (ad esempio 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 le molti aspetti dell'evento, tra cui i frame nell'analisi dello stack, messaggio di eccezione, il codice di errore e un'altra piattaforma o tipo di errore caratteristiche.

Tuttavia, all'interno di questo gruppo di eventi, le analisi dello stack che hanno portato all'errore potrebbe essere diverso. 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 diverse cause principali portano all'errore.

Ecco cosa riscontrerai con i miglioramenti apportati:

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

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

• Debug più semplice dei 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 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 problema.

• Se non esistono corrispondenze, applicheremo automaticamente il nostro raggruppamento di eventi più intelligente all'evento e creare un nuovo problema con i metadati aggiornati la progettazione.

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

Non visibili metriche senza arresti anomali e/o avvisi di velocità

Se non visualizzi le metriche relative alle app senza arresti anomali (ad esempio utenti e sessioni senza arresti anomali) e/o gli avvisi sulla velocità, assicurati di utilizzare l'SDK Crashlytics 18.6.0 o versioni successive (o Firebase BoM v32.6.0 o versioni successive).

Log dei breadcrumb non visualizzati

Se non vedi 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 ha aggiunto l'SDK Firebase per Google Analytics alla tua app. Questo SDK deve essere aggiunto oltre all'SDK Crashlytics.

• Utilizzi le versioni più recenti dell'SDK Firebase per tutti i prodotti che utilizzi nella tua app.

  In particolare, assicurati di utilizzare almeno la versione seguente del SDK Firebase per Google Analytics:
  Android: 17.2.3 e versioni successive (BoM 24.7.1 e versioni successive).

Perché vengono visualizzati solo gli errori ANR segnalato 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 errori ANR (getStoricoProcessExitReasons) è più affidabile di SIGQUIT o degli approcci basati su watchdog. Questa API è disponibile solo sui dispositivi Android 11 e versioni successive.

Perché in alcuni ANR mancano i BuildId?

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

• Assicurati di utilizzare una versione aggiornata dell'CrashlyticsSDK Android e del Crashlyticsplug-in Gradle.

  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 non aggiornati. Per raccogliere correttamente gli errori BuildId per questi errori ANR, devi utilizzare quanto segue versioni:

  • Crashlytics SDK Android 18.3.5 e versioni successive (Firebase BoM 31.2.2 e versioni successive)
  • Crashlytics Plug-in Gradle 2.9.4 o versioni successive

• Verifica se utilizzi una posizione non standard per le librerie condivise.

  Se ti mancano solo BuildId per le raccolte condivise della tua app, è probabile che non stai 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 utilizzare la posizione standard per le librerie condivise.

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

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

  • Controlla se i BuildId esistono eseguendo readelf -n sui tuoi file binari. Se gli attributi BuildId non sono presenti, quindi aggiungi -Wl,--build-id ai flag per la tua di un sistema di compilazione.

  • Assicurati di non rimuovere involontariamente gli BuildId nel tentativo per ridurre le dimensioni dell'APK.

  • Se continui a rimuovere e a rimuovere gli elenchi di elementi di una libreria, assicurati di: punta alla versione corretta del tuo codice.

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

Può esserci una mancata corrispondenza tra il conteggio degli ANR tra Google Play e Crashlytics. Si tratta di un comportamento previsto a causa delle differenze nel meccanismo di raccogliendo e segnalando dati ANR. Crashlytics segnala errori ANR quando l'app si avvia successivamente, mentre Android vitals invia i dati ANR dopo che si verifica l'errore ANR.

Inoltre, Crashlytics mostra solo gli ANR che si verificano sui dispositivi con Android 11 e versioni successive, a differenza di Google Play che mostra gli ANR dei dispositivi su cui sono stati accettati Google Play Services e il consenso alla raccolta dei dati.

Differenze tra le tracce 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 delle app binarie, che potrebbero generare tracce dello stack incoerenti nella console Firebase. Per ovviare a questo problema, aggiungi i seguenti flag del linker al processo di compilazione:

• 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 due flag è pertinente alla tua toolchain), prova ad aggiungere quanto segue al processo di compilazione anziché:

-fno-omit-frame-pointer

Come faccio a utilizzare il mio file 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 file binario per generare i file di simboli di Breakpad (ad esempio, se preferisci compilare tutti gli eseguibili nativi nella catena di compilazione dal codice sorgente), utilizza la proprietà facoltativa di estensione symbolGeneratorBinary per specificare il percorso dell'eseguibile.

Nota: per utilizzare il generatore di file di simboli Breakpad è necessaria la versione Linux Programmi binari di Android.

Puoi specificare il percorso del file binario del generatore di file di simboli Breakpad in uno di due 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 3.0.0 o versioni successive

  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 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 linea di proprietà in Gradle file delle proprietà

  Puoi usare com.google.firebase.crashlytics.breakpadBinary per specificare il percorso dell'eseguibile.

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

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

Nessun arresto anomalo con Dexguard

Se viene visualizzata 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 provoca l'arresto anomalo della tua app, ma impedisce che invii l'arresto anomalo report. Per risolvere il problema:

1. Assicurati di utilizzare l'ultima release 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
   

Perché visualizzo arresti anomali da .kt file con etichetta .java problemi?

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

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

• Android Gradle 4.2.0 o versioni successive
• Utilizza R8 con l'offuscamento attivato. Per aggiornare l'app alla versione R8, segui queste istruzioni documentazione.

Tieni presente che dopo l'aggiornamento alla configurazione descritta in precedenza, potresti iniziare a vedere nuovi problemi di .kt che sono duplicati di problemi di .java esistenti. Consulta le Domande frequenti per saperne di più al riguardo.

Perché vedo .kt problemi che sono duplicati di problemi .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 di file.

Grazie a questo aggiornamento, Crashlytics ora può determinare se ogni corso utilizzato all'interno l'app è scritta in Kotlin e includere il nome file corretto nel problema firma. Ora gli arresti anomali vengono attribuiti correttamente ai file .kt (a seconda dei casi) se la tua app ha la seguente configurazione:

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

Dato che i nuovi arresti anomali ora includono l'estensione del file corretta nel problema firme, potresti vedere nuovi .kt problemi che sono in realtà solo duplicati di problemi esistenti etichettati con .java. Nella console Firebase, proviamo a identificare e ti comunicherà se un nuovo problema di .kt è un possibile duplicato di un problema esistente con etichetta .java.

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 sullo 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 viene descritto l'accesso necessario per visualizzare, scrivere ed eliminare Note:

• I membri del progetto con uno dei seguenti ruoli possono visualizzare ed eliminare quelli esistenti note 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 un problema, ma non possono eliminare o scrivere una nota.

  • 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 sullo 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 viene descritto l'accesso necessario per visualizzare, scrivere ed eliminare 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 progetto, Visualizzatore Firebase, Visualizzatore della qualità, o Visualizzatore Crashlytics

Integrazioni

L'app utilizza anche SDK Google Mobile Ads, ma senza arresti anomali

Se il tuo progetto utilizza Crashlytics insieme all'SDK Google Mobile Ads, è probabile che i reporter sugli arresti anomali interferiscano quando la registrazione di gestori di eccezioni. Per risolvere il problema, disattiva i report sugli arresti anomali in l'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.

Supporto delle piattaforme

Crashlytics supporta gli armeabi?

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

Problemi di regressione

Che cos'è un modello pregresso problema?

Si è verificato un problema di regressione quando l'hai chiuso in precedenza, ma Crashlytics riceve una nuova segnalazione che indica che il problema si è verificato. Crashlytics riapre automaticamente questi problemi pregressi per consentirti affrontarli 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 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 il bug, chiudi il problema "A" e rilasci una nuova versione di la 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 arresto anomalo per qualsiasi arresto anomalo), Crashlytics non prenderà in considerazione il problema come pregresso. Il problema rimarrà chiuso.
   • Se il report proviene da una versione dell'app che Crashlytics ha non informazioni quando hai chiuso il problema (ossia la versione aveva non ha mai inviato alcun report sugli arresti anomali per nessun arresto anomalo), quindi Crashlytics considera che il problema sia pregresso e riaprirà lo problema.

Nota: prima di febbraio 2022, Crashlytics classificava un problema come regressione quando si verificava di nuovo in qualsiasi versione dell'app, anche per le versioni dell'app di cui eravamo a conoscenza al momento della chiusura del problema. Ciò ha comportato Crashlytics a volte l'identificazione imprecisa delle regressioni. Ora utilizziamo la convenzione descritta sopra.

Quando un problema regredisce, inviamo un avviso di rilevamento di regressione e aggiungiamo segnale di regressione al problema per indicarti che Crashlytics ha 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 i dati pregressi problemi con le 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 queste versioni precedenti non ha 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 attiveranno 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 di regressione quando il problema si è ripresentato in qualsiasi versione dell'app, anche nelle versioni dell'app. di cui sapevamo quando hai chiuso il problema. Di conseguenza, Crashlytics a volte le regressioni non venivano identificate con precisione. Ora utilizziamo la convenzione descritta sopra.

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