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 w niektórych przypadkach projekt może nie zostać w pełni skonfigurowany. Z tego przewodnika dowiesz się, co robi automatyzacja, i poznasz pierwsze kroki, które pomogą Ci w debugowaniu konfiguracji 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.

Sprawdź, czy w pliku build.gradle na poziomie projektu i w pliku build.gradle na poziomie aplikacji znajdują się te wiersze:

  • 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.

Aby przesłać symbole 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.