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 .
Risoluzione dei problemi generali/FAQ
Se non visualizzi utenti senza arresti anomali, registri breadcrumb e/o avvisi sulla velocità, ti consigliamo di controllare la configurazione della tua app per Google Analytics.
Assicurati di aver abilitato Google Analytics nel tuo progetto Firebase.
Assicurati che la condivisione dei dati sia abilitata per Google Analytics nella pagina Integrazioni > Google Analytics della console Firebase. Tieni presente che le impostazioni di condivisione dei dati vengono visualizzate nella console di Firebase ma gestite nella console di Google Analytics.
Oltre all'SDK Firebase Crashlytics, assicurati di aver aggiunto l'SDK Firebase per Google Analytics alla tua app ( iOS+ | Android ).
Assicurati di utilizzare le versioni più recenti per tutti i tuoi SDK Firebase ( iOS+ | Android ).
Verifica in particolare di utilizzare almeno le seguenti versioni dell'SDK di Firebase per Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ per macOS e tvOS) | Android — v17.2.3+(BoM v24.7.1+) .
Potresti notare due diversi formati per i problemi elencati nella tabella Problemi nella console Firebase. E potresti anche notare una funzionalità chiamata "varianti" all'interno di 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 sul blog per tutti i dettagli, ma puoi leggere di seguito per i punti salienti.
Crashlytics analizza tutti gli eventi della tua app (come arresti anomali, 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, inclusi 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 hanno portato all'errore potrebbero essere diverse. Un'analisi dello stack diversa potrebbe significare 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 stanno causando l'errore.
Ecco cosa sperimenterai con questi miglioramenti:
Metadati rinnovati visualizzati all'interno della riga del problema
Ora è più facile comprendere e valutare i problemi nella tua app.Meno problemi di duplicazione
Una modifica del numero di riga non comporta un nuovo problema.Debug più semplice di problemi complessi con varie cause alla radice
Utilizza le varianti per eseguire il debug delle analisi dello stack più comuni all'interno di un problema.Avvisi e segnali più significativi
Un nuovo problema rappresenta in realtà un nuovo bug.Ricerca più potente
Ogni numero contiene più metadati ricercabili, come il tipo di eccezione e il nome del pacchetto.
Ecco come vengono implementati questi miglioramenti:
Quando riceviamo nuovi eventi dalla tua app, verificheremo se corrispondono a un problema esistente.
Se non ci sono corrispondenze, 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 nostro raggruppamento di eventi. Se hai feedback o riscontri problemi, faccelo sapere inviando una segnalazione.
Crashlytics supporta la segnalazione ANR per le app Android da dispositivi che eseguono Android 11 e versioni successive. L'API sottostante che usiamo per raccogliere ANR ( getHistoricalProcessExitReasons ) è più affidabile di SIGQUIT o degli approcci basati su watchdog. Questa API è disponibile solo su dispositivi Android 11+.
Se ad alcuni dei tuoi ANR mancano i BuildId , risolvi i problemi come segue:
Assicurati di utilizzare una versione aggiornata dell'SDK Android di Crashlytics e del plug-in Gradle di Crashlytics.
Se mancano
BuildIds per Android 11 e alcuni ANR di Android 12, è probabile che tu stia utilizzando un SDK obsoleto, un plug-in Gradle o entrambi. Per raccogliere correttamenteBuildIdper questi ANR, devi utilizzare le seguenti versioni:- Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
- Plug-in Crashlytics Gradle v2.9.4+
Controlla se stai utilizzando una posizione non standard per le tue librerie condivise.
Se ti mancano solo
BuildIds per le librerie condivise della tua app, è probabile che tu non stia usando il percorso predefinito standard per le librerie condivise. In tal caso, Crashlytics potrebbe non essere in grado di individuare iBuildIdassociati. Si consiglia di prendere in considerazione l'utilizzo della posizione standard per le librerie condivise.Assicurati di non rimuovere
BuildIds durante il processo di compilazione.Tieni presente che i seguenti suggerimenti per la risoluzione dei problemi si applicano sia agli ANR che agli arresti anomali nativi.
Controlla se i
BuildIdesistono eseguendoreadelf -nsui tuoi binari. Se iBuildIdsono assenti, aggiungi-Wl,--build-idai flag per il tuo sistema di compilazione.Verifica di non rimuovere involontariamente i
BuildIdnel tentativo di ridurre le dimensioni dell'APK.Se mantieni versioni estratte e non estratte di una libreria, assicurati di puntare alla versione corretta nel tuo codice.
Potrebbe esserci una discrepanza tra il conteggio degli ANR tra Google Play e Crashlytics. Ciò è previsto a causa della differenza nel meccanismo di raccolta e comunicazione dei dati ANR. Crashlytics segnala gli ANR al successivo avvio dell'app, mentre Android Vitals invia i dati ANR dopo che si è verificato l'ANR.
Inoltre, Crashlytics mostra solo gli ANR che si verificano sui dispositivi con Android 11+, rispetto a Google Play che mostra gli ANR dai dispositivi con Google Play Services e il consenso alla raccolta dei dati accettato.
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 tracce dello stack incoerenti nella console Firebase. Per mitigare questo, aggiungi i seguenti flag del linker al tuo processo di compilazione:
Se stai utilizzando il linker
llddalla toolchain LLVM, aggiungi:-Wl,--no-rosegmentSe stai usando il linker
ld.golddalla toolchain GNU, aggiungi:-Wl,--rosegment
Se continui a riscontrare incoerenze nella traccia dello stack (o se nessuno dei due flag è pertinente alla tua toolchain), prova invece ad aggiungere quanto segue al processo di compilazione:
-fno-omit-frame-pointer
Il plug-in Crashlytics include un generatore di file di simboli Breakpad personalizzato . Se preferisci usare il tuo file binario per generare file di simboli Breakpad (ad esempio, se preferisci creare tutti gli eseguibili nativi nella catena di compilazione dall'origine), usa la proprietà di estensione facoltativa symbolGeneratorBinary per specificare il percorso dell'eseguibile.
È possibile specificare il percorso del binario del generatore di file di simboli Breakpad in uno dei due modi seguenti:
Opzione 1 : specificare il percorso tramite l'estensione
firebaseCrashlyticsnel filebuild.gradleAggiungi quanto segue al tuo file
build.gradlea livello di app: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 : specificare il percorso tramite una linea di proprietà nel file delle proprietà Gradle
Puoi utilizzare la proprietà
com.google.firebase.crashlytics.symbolGeneratorBinaryper specificare il percorso dell'eseguibile.Puoi aggiornare manualmente il file delle proprietà di Gradle o aggiornare il file tramite la riga di comando. Ad esempio, per specificare il percorso tramite la riga di comando, utilizzare un comando simile al seguente:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
Se visualizzi la seguente eccezione, è probabile che tu stia utilizzando una versione di DexGuard incompatibile con Firebase Crashlytics SDK:
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
Questa eccezione non provoca l'arresto anomalo dell'app, ma le impedisce di inviare rapporti sugli arresti anomali. Per risolvere questo problema:
Assicurati di utilizzare l'ultima versione di DexGuard 8.x. L'ultima versione contiene le regole richieste dall'SDK di Firebase Crashlytics.
Se non desideri 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
Quando un'app utilizza un offuscatore che non espone l'estensione del file, Crashlytics genera ogni problema con un'estensione di file .java per impostazione predefinita.
Affinché Crashlytics possa generare problemi con l'estensione di 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 la tua app alla versione R8, segui questa documentazione .
Tieni presente che dopo l'aggiornamento alla configurazione descritta sopra, potresti iniziare a vedere nuovi problemi .kt che sono duplicati di problemi .java esistenti. Consulta le FAQ per saperne di più su questa circostanza.
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 di file .java per impostazione predefinita. Tuttavia, a partire da Android Gradle 4.2.0, R8 supporta le estensioni di file.
Con questo aggiornamento, Crashlytics può ora 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:
- 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 di file corretta nelle firme dei problemi, potresti vedere nuovi problemi .kt che in realtà sono solo duplicati di problemi con etichetta .java esistenti. Nella console di Firebase, cerchiamo di identificare e comunicarti se un nuovo problema .kt è un possibile duplicato di un problema esistente con etichetta .java .
Il valore senza arresti anomali rappresenta la percentuale di utenti che hanno interagito con la tua app ma non hanno subito arresti anomali in un periodo di tempo specifico.
Ecco la formula per calcolare la percentuale di utenti senza arresti anomali. I suoi valori di input sono forniti da Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
Quando si verifica un arresto anomalo, Google Analytics invia un tipo di evento
app_exceptione CRASHED_USERS rappresenta il numero di utenti associati a tale tipo di evento.ALL_USERS rappresenta il numero totale di utenti che hanno interagito con la tua app nel periodo di tempo selezionato dal menu a discesa in alto a destra nella dashboard di Crashlytics.
La percentuale di utenti senza arresti anomali è un'aggregazione nel tempo , non una media.
Ad esempio, immagina che la tua app abbia tre utenti; li chiameremo Utente A, Utente B e Utente C. La tabella seguente mostra quali utenti hanno interagito con la tua app ogni giorno e quali di questi utenti hanno avuto un arresto anomalo quel giorno:
| Lunedi | Martedì | Mercoledì | |
|---|---|---|---|
| Utenti che hanno interagito con la tua app | A,B,C | A,B,C | A, B |
| Utente che ha avuto un arresto anomalo | C | B | UN |
Mercoledì, la percentuale di utenti senza arresti anomali è del 50% (1 utente su 2 non ha avuto arresti anomali).
Due dei tuoi utenti hanno interagito con la tua app mercoledì, ma solo uno di loro (l'utente B) non ha avuto arresti anomali.Negli ultimi 2 giorni, la percentuale di utenti senza arresti anomali è stata del 33,3% (1 utente su 3 non ha avuto arresti anomali).
Tre dei tuoi utenti hanno interagito con la tua app negli ultimi due giorni, ma solo uno di loro (Utente C) non ha avuto arresti anomali.Negli ultimi 3 giorni, la percentuale di utenti senza arresti anomali è stata dello 0% (0 utenti su 3 non hanno avuto arresti anomali).
Tre dei tuoi utenti hanno interagito con la tua app negli ultimi tre giorni, ma nessuno di loro ha avuto arresti anomali.
Le note consentono ai membri del progetto di commentare problemi specifici con domande, aggiornamenti di stato, ecc.
Quando un membro del progetto pubblica una nota, viene etichettata con l'email del proprio account Google. Questo indirizzo email è visibile, insieme alla nota, a tutti i membri del progetto con accesso per visualizzare la nota.
Di seguito viene 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 eliminare o scrivere una nota.
Integrazioni
Se il tuo progetto utilizza Crashlytics insieme a Google Mobile Ads SDK, è probabile che i segnalatori di arresti anomali stiano interferendo durante la registrazione dei gestori di eccezioni. Per risolvere il problema, disattiva la segnalazione degli arresti anomali nell'SDK Mobile Ads chiamando disableSDKCrashReporting .
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
Firebase Crashlytics NDK non supporta ARMv5 (armeabi). Il supporto per questo ABI è stato rimosso a partire da NDK r17.
Problemi regrediti
Un problema ha avuto una regressione quando in precedenza l'avevi chiuso, ma Crashlytics riceve un nuovo rapporto che il problema si è ripresentato. Crashlytics riapre automaticamente questi problemi regrediti in modo che tu possa risolverli in modo appropriato per la tua app.
Ecco uno scenario di esempio che spiega come Crashlytics classifica un problema come regressione:
- Per la prima volta in assoluto, Crashlytics riceve un rapporto sugli arresti anomali relativi a Crash "A". Crashlytics apre un problema corrispondente per quell'arresto anomalo (Problema "A").
- Correggi rapidamente questo bug, chiudi il problema "A" e poi rilasci una nuova versione della tua app.
- Crashlytics riceve un altro rapporto sul problema "A" dopo che hai chiuso il problema.
- Se il rapporto proviene da una versione dell'app di cui Crashlytics era a conoscenza quando hai chiuso il problema (il che significa che la versione aveva inviato un rapporto sugli arresti anomali per qualsiasi arresto anomalo), allora Crashlytics non considererà il problema come regredito. La questione rimarrà chiusa.
- Se la segnalazione proviene da una versione dell'app di cui Crashlytics non era a conoscenza quando hai chiuso il problema (il che significa che la versione non aveva mai inviato alcuna segnalazione di arresto anomalo per nessun arresto anomalo), allora Crashlytics considera il problema regredito e lo riaprirà .
Quando un problema regredisce, inviamo un avviso di rilevamento della regressione e aggiungiamo un segnale di regressione al problema per informarti che Crashlytics ha riaperto il problema. Se non vuoi che un problema si riapra a causa del nostro algoritmo di regressione, "silenzia" il problema invece di chiuderlo.
Se un rapporto proviene da una vecchia versione dell'app che non aveva mai inviato alcun rapporto sugli arresti anomali quando hai chiuso il problema, allora Crashlytics considera il problema regredito e lo riaprirà.
Questa situazione può verificarsi nella situazione seguente: hai corretto un bug e rilasciato una nuova versione della tua app, ma hai ancora utenti su versioni precedenti senza la correzione del bug. Se, per caso, una di quelle versioni precedenti non avesse mai inviato alcun rapporto sugli arresti anomali quando hai chiuso il problema e quegli utenti iniziassero a riscontrare il bug, allora quei rapporti sugli arresti anomali attiverebbero un problema regredito.
Se non vuoi che un problema si riapra a causa del nostro algoritmo di regressione, "silenzia" il problema invece di chiuderlo.