Risoluzione dei problemi e domande frequenti su Crashlytics

bookmark_border Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Potresti notare due formati diversi per i problemi elencati nella tabella Problemi della console Firebase. Potresti anche notare una funzionalità chiamata "varianti" all'interno di alcuni problemi. Ecco perché.

All'inizio del 2023 abbiamo implementato un motore di analisi migliorato per il raggruppamento degli eventi, oltre a un design aggiornato e alcune funzionalità avanzate per i nuovi problemi (come le varianti). Consulta il nostro recente post del blog per tutti i dettagli, ma puoi leggere di seguito i punti salienti.

Crashlytics analizza tutti gli eventi della tua app (come 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, inclusi i frame nello stack trace, 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 cause principali diverse portano all'errore.

Ecco cosa potrai fare con questi miglioramenti:

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

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

• Debug più semplice di 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 metadati più ricercabili, come il tipo di eccezione e il nome del pacchetto.

Ecco come vengono implementati questi miglioramenti:

• Quando riceviamo nuovi eventi dalla tua app, verifichiamo se corrispondono a un problema esistente.

• Se non viene trovata una corrispondenza, applicheremo automaticamente il nostro algoritmo di raggruppamento degli eventi più intelligente all'evento e creeremo un nuovo problema con il design dei metadati rinnovato.

Questo è il primo grande aggiornamento che apportiamo al raggruppamento degli eventi. Se hai feedback o riscontri problemi, comunicacelo inviando una segnalazione.

Se non visualizzi i 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 aggiunto l'SDK Firebase per Google Analytics alla tua app. Questo SDK deve essere aggiunto in aggiunta all'SDK Crashlytics.

• Stai utilizzando le ultime versioni dell'SDK Firebase per tutti i prodotti che utilizzi nella tua app.

  Controlla in particolare di utilizzare almeno la seguente versione dell'SDK Firebase per Google Analytics:
  Android: versione 17.2.3+ (BoM versione 24.7.1+).

Se non visualizzi gli avvisi di velocità, assicurati di utilizzare l'SDK Crashlytics v18.6.0 o versioni successive (o Firebase BoM v32.6.0 o versioni successive).

Se non visualizzi le metriche relative agli arresti anomali (ad esempio utenti e sessioni senza arresti anomali) o se le metriche non sono affidabili, controlla quanto segue:

• Assicurati di utilizzare l'SDK Crashlytics v18.6.0 o versioni successive (o Firebase BoM v32.6.0 o versioni successive).

• Assicurati che le impostazioni di raccolta dei dati non influiscano sulla qualità delle metriche senza arresti anomali:

  • Se attivi i report con consenso disattivando i report sugli arresti anomali automatici, le informazioni sugli arresti anomali possono essere inviate a Crashlytics solo dagli utenti che hanno attivato esplicitamente la raccolta dei dati. Pertanto, l'accuratezza delle metriche senza arresti anomali sarà interessata, poiché Crashlytics dispone solo delle informazioni sugli arresti anomali di questi utenti che hanno attivato la funzionalità (anziché di tutti gli utenti). Ciò significa che le metriche senza arresti anomali potrebbero essere meno affidabili e meno rappresentative della stabilità complessiva della tua app.

  • Se hai disattivato la raccolta automatica dei dati, puoi utilizzare sendUnsentReports per inviare a Crashlytics i report memorizzati nella cache sul dispositivo. L'utilizzo di questo metodo invierà i dati relativi agli arresti anomali a Crashlytics, ma non i dati relativi alle sessioni, il che fa sì che i grafici della console mostrino valori bassi o pari a zero per le metriche senza arresti anomali.

Consulta la sezione Comprendere le metriche senza arresti anomali.

Crashlytics supporta la segnalazione di errori ANR per le app per Android dai dispositivi con Android 11 e versioni successive. L'API sottostante che utilizziamo per raccogliere gli errori ANR (getHistoricalProcessExitReasons) è più affidabile degli approcci basati su SIGQUIT o watchdog. Questa API è disponibile solo sui dispositivi Android 11 e versioni successive.

Se alcuni dei tuoi errori ANR non hanno BuildId, risolvi il problema nel seguente modo:

• Assicurati di utilizzare una versione aggiornata dell'SDK Android Crashlytics e del plug-in Gradle Crashlytics.

  Se mancano BuildId per Android 11 e alcuni errori ANR di Android 12, è probabile che tu stia utilizzando un SDK, un plug-in Gradle o entrambi non aggiornati. Per raccogliere correttamente i BuildId per questi errori ANR, devi utilizzare le seguenti versioni:

  • Crashlytics SDK Android v18.3.5+ (Firebase BoM v31.2.2+)
  • Crashlytics Plug-in Gradle v2.9.4+

• Controlla se stai utilizzando una posizione non standard per le librerie condivise.

  Se mancano soloBuildIdper 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 i BuildId associati. Ti consigliamo di prendere in considerazione l'utilizzo della posizione standard per le librerie condivise.

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

  Tieni presente che i seguenti suggerimenti per la risoluzione dei problemi si applicano sia agli errori ANR sia agli arresti anomali nativi.

  • Controlla se esistono BuildId eseguendo readelf -n sui tuoi binari. Se i BuildId non sono presenti, aggiungi -Wl,--build-id ai flag per il tuo sistema di compilazione.

  • Verifica di non rimuovere involontariamente le BuildId per ridurre le dimensioni dell'APK.

  • Se conservi le versioni con e senza simboli di debug di una libreria, assicurati di puntare alla versione corretta nel codice.

Potrebbe esserci una mancata corrispondenza tra il conteggio degli errori ANR tra Google Play e Crashlytics. Ciò è previsto a causa della differenza nel meccanismo di raccolta e generazione di report sui dati ANR. Crashlytics segnala gli errori ANR al successivo avvio dell'app, mentre Android vitals invia i dati ANR dopo che si è verificato l'errore ANR.

Inoltre, Crashlytics mostra solo gli ANR che si verificano sui dispositivi con Android 11 o versioni successive, mentre Google Play mostra gli ANR dei 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 dell'app, il che potrebbe generare stack trace incoerenti nella console Firebase. Per risolvere il problema, aggiungi i seguenti flag del linker al processo di build:

• 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 nella traccia dello stack (o se nessuno dei flag è pertinente alla tua toolchain), prova ad aggiungere quanto segue al processo di build invece:

-fno-omit-frame-pointer

Il plug-in Crashlytics include un generatore di file di simboli Breakpad personalizzato. Se preferisci utilizzare il tuo binario per generare file di simboli Breakpad (ad esempio, se preferisci creare tutti gli eseguibili nativi nella tua catena di build dal codice sorgente), utilizza la proprietà di estensione facoltativa symbolGeneratorBinary per specificare il percorso dell'eseguibile.

Puoi specificare il percorso del file binario del generatore di file di simboli Breakpad in uno dei due modi seguenti:

• 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 v3.0.0+ versioni precedenti del plug-in Altro
  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")
        }
      }
    }
  }

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

  Puoi utilizzare la proprietà com.google.firebase.crashlytics.breakpadBinary per specificare il percorso dell'eseguibile.

  Puoi aggiornare manualmente il file delle proprietà di Gradle o aggiornarlo 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
  

Se visualizzi 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 impedisce l'invio di report sugli arresti anomali. Per risolvere il problema:

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

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

Affinché Crashlytics possa generare problemi con l'estensione 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, consulta 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 circostanza, consulta le Domande frequenti.

A partire da metà dicembre 2021, Crashlytics è stato 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 dei file.

Con questo aggiornamento, Crashlytics ora può determinare se ogni classe utilizzata nell'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 file corretta nelle firme dei problemi, potresti visualizzare nuovi problemi .kt che in realtà sono solo duplicati di problemi esistenti con l'etichetta .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.

Le note consentono ai membri del progetto di commentare problemi specifici con domande, aggiornamenti di stato e così via.

Quando un membro del progetto pubblica una nota, questa viene etichettata con l'email del suo Account Google. Questo indirizzo email è visibile, insieme alla nota, a tutti i membri del progetto con accesso alla visualizzazione della 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 in un problema, ma non possono eliminarle o scriverne una.

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

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

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

Un problema ha subito una regressione quando lo hai chiuso in precedenza, ma Crashlytics riceve una nuova segnalazione che indica che il problema si è ripresentato. Crashlytics riapre automaticamente questi problemi di regressione in modo che tu possa risolverli nel modo più 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 questo 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 era a conoscenza quando hai chiuso il problema (ovvero la versione aveva inviato un report sugli arresti anomali per qualsiasi arresto anomalo), allora Crashlytics non considererà il problema come regresso. Il problema rimarrà chiuso.
   • Se la segnalazione proviene da una versione dell'app che Crashlytics non conosceva quando hai chiuso il problema (ovvero la versione non aveva mai inviato alcuna segnalazione di arresto anomalo), allora Crashlytics considera il problema come regredito e lo riaprirà.

Quando un problema regredisce, inviamo un avviso di rilevamento della regressione e aggiungiamo un indicatore di regressione al problema per comunicarti che Crashlytics ha riaperto il problema. Se non vuoi che un problema venga riaperto a causa del nostro algoritmo di regressione, "silenzia" il problema anziché chiuderlo.

Se un report proviene da una vecchia versione dell'app che non aveva mai inviato report sugli arresti anomali quando hai chiuso il problema, Crashlytics considera il problema regredito e lo riaprirà.

Questa situazione può verificarsi quando hai corretto un bug e hai rilasciato una nuova versione dell'app, ma ci sono ancora utenti che utilizzano versioni precedenti senza la correzione del bug. Se, per caso, una di queste versioni precedenti non avesse 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 attiverebbero un problema di regressione.

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