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 stai cercando o hai bisogno di ulteriore aiuto, contatta il supporto di Firebase .
Risoluzione dei problemi generali/FAQ
Se non visualizzi utenti senza arresti anomali, registri breadcrumb e/o avvisi di 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 Firebase per Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ per macOS e tvOS) | Android — v17.2.3+(BOM v24.7.1+) .
Il valore senza arresti anomali rappresenta la percentuale di utenti che hanno interagito con la tua app ma non hanno avuto un arresto anomalo in un determinato periodo di tempo. Seleziona questo periodo di tempo dal menu a discesa in alto a destra del 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 interagiscono 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 era senza arresti anomali).
Mercoledì due dei tuoi utenti hanno interagito con la tua app, ma solo uno di loro (Utente B) non ha avuto arresti anomali.Negli ultimi 2 giorni, la percentuale di utenti senza arresti anomali è 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 è 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.
Se necessario, ecco gli input specifici e la formula per il calcolo della percentuale di utenti senza crash:
1 - ( IMPACTED_USERS / ALL_USERS )
Dove IMPACTED_USERS e ALL_USERS sono raccolti da Google Analytics e disponibili tramite la dashboard di Analytics.
Integrazioni
Se il tuo progetto utilizza Crashlytics insieme a Google Mobile Ads SDK, è probabile che i segnalatori di arresti anomali interferiscano durante la registrazione dei gestori delle eccezioni. Per risolvere il problema, disattiva la segnalazione degli arresti anomali in Mobile Ads SDK 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
Problemi regrediti
Un problema ha avuto una regressione quando hai precedentemente chiuso il problema, 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 una regressione:
- Per la prima volta in assoluto, Crashlytics riceve un rapporto di arresto anomalo su Crash "A". Crashlytics apre un problema corrispondente per quell'arresto anomalo (Problema "A").
- Risolvi rapidamente questo bug, chiudi il problema "A" e quindi rilascia una nuova versione dell'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 di arresto anomalo per qualsiasi arresto anomalo), Crashlytics non considererà il problema come regredito. La questione rimarrà chiusa.
- Se il rapporto 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 ha mai inviato alcun rapporto di arresto anomalo per nessun arresto anomalo), 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 si desidera che un problema si riapra a causa del nostro algoritmo di regressione, disattivare l'audio del problema invece di chiuderlo.
Se un rapporto proviene da una vecchia versione dell'app che non aveva mai inviato alcun rapporto di arresto anomalo quando hai chiuso il problema, Crashlytics considera il problema regredito e lo riaprirà.
Questa situazione può verificarsi nella seguente situazione: 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 ha mai inviato alcun rapporto di arresto anomalo quando hai chiuso il problema e quegli utenti iniziano a riscontrare il bug, tali rapporti di arresto anomalo attiverebbero un problema regredito.
Se non si desidera che un problema si riapra a causa del nostro algoritmo di regressione, disattivare l'audio del problema invece di chiuderlo.