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ą deobfuskację raportów o awariach i ich czytelność.

Niestety w niektórych przypadkach projekt może nie zostać w pełni skonfigurowany. Ten przewodnik zawiera opis działania automatyzacji i pierwsze kroki, które należy wykonać, aby debugować konfigurację projektu.

Platformy Apple

Sprawdzanie konfiguracji przesyłania plików dSYM

Dodanie Crashlytics wtyczki Fluttera i uruchomienie polecenia flutterfire configure spowoduje próbę dodania do obszaru roboczego Xcode projektu skryptu uruchamiania, który znajdzie i prześle niezbędne pliki symboli dSYM do Crashlytics. Bez tych plików w panelu Crashlytics zobaczysz alert „Brak pliku dSYM”, a wyjątki będą przechowywane na serwerze backendu do momentu przesłania brakujących plików.

Jeśli wystąpi ten problem, najpierw sprawdź, czy masz zainstalowany skrypt uruchamiania:

  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 elementu docelowego Runner dodano skrypt o nazwie [firebase_crashlytics] Crashlytics Upload Symbols.

    W odpowiedniej sekcji poniżej sprawdź, czy skrypt nie istnieje lub istnieje.

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

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

Upewnij się, że w projekcie używasz zalecanej konfiguracji wersji (Flutter 3.12.0 lub nowszy i Crashlytics wtyczka Fluttera 3.3.4 lub nowsza), aby projekt mógł automatycznie generować i przesyłać symbole Fluttera (pliki dSYM) do Crashlytics.

Android

Sprawdzanie konfiguracji 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 konsoli Firebase mogą być zaciemnione, jeśli zaciemnianie jest włączone.

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ź, czy jest w nim 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ź, czy znajduje się w nim 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 Fluttera używasz interfejsu wiersza poleceń (jeśli używasz flagi --split-debug-info).

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

Użyj Firebase CLI (wersja 11.9.0 lub nowsza), aby przesłać symbole debugowania Fluttera. Zanim zgłosisz awarię z kompilacji kodu zaciemnionego, musisz przesłać symbole debugowania.

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ładowy identyfikator aplikacji Firebase na Androida: 1:567383003300:android:17104a2ced0c9b9b

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

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