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 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: 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 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 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 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 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.
Non vengono visualizzate le metriche senza arresti anomali e/o gli avvisi sulla 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).
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 aggiunto l'SDK Firebase per Google Analytics alla tua app. 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.
In particolare, verifica di utilizzare almeno la seguente versione dell'SDK Firebase per Google Analytics:
Android - v17.2.3 e versioni successive (BoM v24.7.1 e versioni successive) .
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 di base 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 per 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
BuildIdper 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 iBuildIdper questi ANR, devi utilizzare le seguenti versioni:- Crashlytics SDK Android 18.3.5 e versioni successive (Firebase BoM 31.2.2 e versioni successive)
- Crashlytics Plug-in Gradle v2.9.4 e versioni successive
Verifica se utilizzi una posizione non standard per le librerie condivise.
Se mancano solo i
BuildIdper 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 iBuildIdassociati. Ti consigliamo di utilizzare la posizione standard per le librerie condivise.Assicurati di non rimuovere i
BuildIddurante 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 file
BuildIdesistono eseguendoreadelf -nsui file binari. Se iBuildIdnon sono presenti, aggiungi-Wl,--build-idai flag per il sistema di compilazione.Verifica di non rimuovere involontariamente i
BuildIdper ridurre le dimensioni dell'APK.Se mantieni le versioni stripped e non stripped 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
Può esserci una mancata corrispondenza tra il conteggio degli ANR tra Google Play e Crashlytics. Questo è normale a causa della differenza nel meccanismo di raccolta e generazione di report dei dati ANR. Crashlytics segnala gli ANR all'avvio successivo dell'app, mentre Android Vitals invia i dati ANR dopo che si verificano.
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 attenuare il problema, aggiungi i seguenti flag linker alla procedura di compilazione:
Se utilizzi il linker
llddella toolchain LLVM, aggiungi:-Wl,--no-rosegmentSe utilizzi il linker
ld.golddella 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 compilazione:
-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 dall'origine), utilizza la proprietà facoltativa di estensione symbolGeneratorBinary per specificare il percorso dell'eseguibile.
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
firebaseCrashlyticsnel filebuild.gradleAggiungi quanto segue al file
build.gradle.ktsa 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 dei 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 Gradle properties
Puoi utilizzare la proprietà
com.google.firebase.crashlytics.breakpadBinaryper 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 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
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 causa l'arresto anomalo dell'app, ma ne impedisce l'invio di report sugli arresti anomali. Per risolvere il problema:
Assicurati di utilizzare la versione più recente di DexGuard 8.x. La versione più recente contiene regole richieste dall'SDK Firebase Crashlytics.
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é 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 per impostazione predefinita 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:
- Utilizza Android Gradle 4.2.0 o versioni successive
- Utilizza R8 con l'offuscamento attivato. Per aggiornare l'app alla versione R8, segui 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 situazione, consulta le
Domande frequenti.
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 dei file.
Con questo aggiornamento, Crashlytics ora può determinare se ogni classe utilizzata all'interno
dell'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:
- L'app utilizzi 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 etichettati come .kt..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.
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 è 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.
I membri del progetto con uno dei seguenti ruoli possono visualizzare le note pubblicate su un problema, ma non possono eliminarle o scriverne una.
Come vengono calcolati gli utenti 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 è 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.
I membri del progetto con uno dei seguenti ruoli possono visualizzare le note pubblicate su un problema, ma non possono eliminarle o scriverne una.
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 segnalatori di arresti anomali interferiscano con la registrazione degli 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.
Supporto della piattaforma
Crashlytics supporta armeabi?
L'NDK di Firebase Crashlytics non supporta ARMv5 (armeabi). Il supporto di questo ABI è stato rimosso a partire dalla versione r17 di NDK.
Problemi di regressione
Che cos'è un problema rientrante?
Si è verificata una regressione di un problema che avevi già chiuso, ma Crashlytics riceve una nuova segnalazione che indica che il problema si è verificato di nuovo. Crashlytics riapre automaticamente questi problemi con regressione in modo che tu possa risolverli in base alle esigenze della tua app.
Ecco uno scenario di esempio che spiega in che modo Crashlytics classifica un problema come regressione:
- 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").
- Correggi rapidamente il bug, chiudi il problema "A" e rilascia una nuova versione della tua app.
- Crashlytics riceve un'altra segnalazione relativa al problema"A" dopo che lo hai chiuso.
- Se il report proviene da una versione dell'app di cui Crashlytics era a conoscenza quando hai chiuso il problema (ovvero la versione ha inviato un report di guasto per qualsiasi guasto), Crashlytics non considererà il problema come regressivo. Il problema rimarrà chiuso.
- Se il report proviene da una versione dell'app di cui Crashlytics non era a conoscenza al momento della chiusura del problema (ovvero la versione non aveva mai inviato nessun report sugli arresti anomali), then Crashlytics considera il problema in regressione e lo riaprirà.
Quando un problema peggiora, inviamo un avviso di rilevamento di regressione e aggiungiamo un indicatore di regressione al problema per informarti che Crashlytics lo ha riaperto. Se non vuoi che un problema venga riaperto a causa del nostro algoritmo di regressione, "disattiva" il problema anziché chiuderlo.
Perché vedo problemi di regressione per 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.