Uzyskiwanie czytelnych raportów o awariach w panelu Crashlytics (Flutter)

Wybierz platformę: iOS+ Android Flutter Unity


Domyślnie Firebase Crashlytics automatycznie instrumentuje projekt Flutter , aby przesyłać niezbędne pliki symboli, które zapewniają, że raporty o awariach są deobfuskowane i czytelne.

Niestety zdarzają się przypadki, w których projekt nie jest w pełni skonfigurowany. Z tego przewodnika dowiesz się, co robi automatyzacja, i poznasz pierwsze kroki, które pozwolą Ci debugować konfigurację projektu.

Platformy Apple

Sprawdź konfigurację przesyłania plików dSYM

Dodanie wtyczki Crashlytics Flutter i uruchomienie polecenia flutterfire configure spowoduje próbę dodania skryptu uruchamiającego do obszaru roboczego Xcode projektu, który znajdzie i prześle niezbędne pliki symboli dSYM do Crashlytics. Bez tych plików w panelu Crashlytics zobaczysz alert „Missing dSYM” (Brak pliku dSYM), a wyjątki będą przechowywane przez backend do czasu przesłania brakujących plików.Crashlytics

Jeśli masz ten problem, najpierw upewnij się, że masz zainstalowany skrypt uruchamiający:

  1. Znajdź i otwórz plik obszaru roboczego Xcode w katalogu iOS projektu (FLUTTER_PROJECT_NAME/ios/Runner.xcworkspace).

  2. Sprawdź, czy do faz kompilacji celu Runner został dodany skrypt uruchamiający o nazwie [firebase_crashlytics] Crashlytics Upload Symbols.

    W odpowiedniej sekcji poniżej sprawdź, czy skrypt uruchamiający nie istnieje, czy skrypt uruchamiający istnieje.

Sprawdź konfigurację wersji Flutter i Crashlytics (jeśli używasz flagi --split-debug-info)

Jeśli projekt Flutter używa flagi --split-debug-info (i opcjonalnie flagi --obfuscate), musisz wykonać dodatkowe czynności, aby wyświetlać czytelne ślady stosu aplikacji.

Upewnij się, że projekt używa zalecanej konfiguracji wersji (Flutter 3.12.0+ i Crashlytics wtyczka Flutter 3.3.4+), aby projekt mógł automatycznie generować i przesyłać symbole Flutter (pliki dSYM) do Crashlytics.

Android

Sprawdź konfigurację zależności

Polecenie flutterfire configure próbuje dodać niezbędne zależności do plików kompilacji Gradle projektu. Bez tych zależności raporty o awariach w Firebase konsoli mogą być zaciemnione, jeśli włączone jest zaciemnianie.

Upewnij się, że te wiersze znajdują się w pliku build.gradle na poziomie projektu i w pliku build.gradle na poziomie aplikacji:

  • W pliku kompilacji na poziomie projektu (android/build.gradle) sprawdź ten wiersz:

    dependencies {
// ... other dependencies

classpath 'com.google.gms:google-services:4.3.5'
classpath 'com.google.firebase:firebase-crashlytics-gradle:2.7.1'
}

  • W pliku kompilacji na poziomie aplikacji (android/app/build.gradle) sprawdź ten wiersz:

    // ... other imports

android {
// ... your android config
}

dependencies {
// ... your dependencies
}

// This section must appear at the bottom of the file
apply plugin: 'com.google.gms.google-services'
apply plugin: 'com.google.firebase.crashlytics'

Sprawdź, czy do przesyłania symboli Flutter używasz interfejsu wiersza poleceń (jeśli używasz flagi --split-debug-info)

Jeśli projekt Flutter używa flagi --split-debug-info (i opcjonalnie flagi --obfuscate), musisz wykonać dodatkowe czynności, aby wyświetlać czytelne ślady stosu aplikacji.

Do przesyłania symboli debugowania Flutter użyj interfejsu wiersza poleceń FirebaseCLI (w wersji 11.9.0 lub nowszej). Musisz przesłać symbole debugowania zanim zgłosisz awarię z kompilacji kodu zaciemnionego.

W katalogu głównym projektu Flutter uruchom to polecenie:

firebase crashlytics:symbols:upload --app=FIREBASE_APP_ID PATH/TO/symbols

  • FIREBASE_APP_ID: identyfikator aplikacji Firebase na Androida (nie nazwa pakietu)
    Przykład identyfikatora aplikacji Firebase na Androida: 1:567383003300:android:17104a2ced0c9b9b

  • PATH/TO/symbols: ten sam katalog, który przekazujesz do flagi --split-debug-info podczas kompilowania aplikacji.

Jeśli problemy nadal występują, zapoznaj się z przewodnikiem dotyczącym rozwiązywania problemów z zaciemnionymi raportami na Androidzie.