דף זה תורגם על ידי Cloud Translation API.

שאלות נפוצות ופתרון בעיות ב-Crashlytics

בדף הזה תוכלו למצוא עזרה בפתרון בעיות ותשובות לשאלות נפוצות לגבי השימוש ב-Crashlytics. אם לא מצאתם את מה שחיפשתם או שאתם צריכים עזרה נוספת, אתם יכולים לפנות לתמיכה של Firebase.

פתרון בעיות כלליות/שאלות נפוצות

רואים פורמטים שונים (ולפעמים 'וריאציות') של חלק מהבעיות בטבלה בעיות

יכול להיות שתבחינו בשני פורמטים שונים של בעיות שמופיעות בטבלה בעיות במסוף Firebase. יכול להיות שתבחינו גם בתכונה שנקראת 'וריאציות' בחלק מהבעיות. הנה הסיבות:

בתחילת 2023 השקנו מנוע ניתוח משופר לקיבוץ אירועים, עיצוב מעודכן וכמה תכונות מתקדמות לבעיות חדשות (כמו וריאציות!). כל הפרטים מופיעים בפוסט האחרון בבלוג, אבל בהמשך מופיעים עיקרי הדברים.

‫Crashlytics מנתח את כל האירועים מהאפליקציה (כמו קריסות, שגיאות לא קריטיות ומקרי ANR) ויוצר קבוצות של אירועים שנקראות בעיות – לכל האירועים בבעיה יש נקודת כשל משותפת.

כדי לקבץ אירועים לבעיות האלה, מנוע הניתוח המשופר בודק עכשיו הרבה היבטים של האירוע, כולל המסגרות במעקב אחר מחסנית, הודעת החריגה, קוד השגיאה ומאפיינים אחרים של הפלטפורמה או של סוג השגיאה.

עם זאת, בתוך קבוצת האירועים הזו, יכול להיות שדוחות הקריסות שמובילים לכשל יהיו שונים. דוח קריסה שונה יכול להצביע על סיבת שורש שונה. כדי לייצג את ההבדל האפשרי הזה בתוך בעיה, אנחנו יוצרים עכשיו וריאציות בתוך בעיות – כל וריאציה היא קבוצת משנה של אירועים בבעיה שיש להם אותה נקודת כשל ו עקבות מחסנית דומים. באמצעות וריאציות, אפשר לנפות באגים במעקב אחר מחסנית (stack trace) הנפוץ ביותר בבעיה, ולקבוע אם סיבות שורש שונות מובילות לכשל.

אלה השיפורים שתוכלו לראות:

מטא-נתונים משופרים שמוצגים בשורת הבעיה
עכשיו קל יותר להבין את הבעיות באפליקציה ולסווג אותן.
פחות בעיות כפולות
שינוי במספר השורה לא גורם ליצירת בעיה חדשה.
ניפוי באגים קל יותר בבעיות מורכבות עם מגוון סיבות שורש
אפשר להשתמש בווריאציות כדי לנפות באגים במעקב אחר מחסנית (stack trace) הנפוץ ביותר בבעיה.
התראות וסיגנלים משמעותיים יותר
בעיה חדשה מייצגת באג חדש.
חיפוש יעיל יותר
כל בעיה מכילה יותר מטא-נתונים שאפשר לחפש, כמו סוג החריגה ושם החבילה.

כך מתבצעת ההשקה של השיפורים האלה:

כשנקבל אירועים חדשים מהאפליקציה, נבדוק אם הם תואמים לבעיה קיימת.
אם אין התאמה, אנחנו נחיל באופן אוטומטי על האירוע את האלגוריתם החכם יותר שלנו לקיבוץ אירועים, וניצור בעיה חדשה עם עיצוב משופר של המטא-נתונים.

זהו העדכון הגדול הראשון שאנחנו מבצעים בקיבוץ האירועים. אם יש לכם משוב או שנתקלתם בבעיות, אתם יכולים לדווח על כך .

לא רואים יומנים של נתיבי מיקום

אם לא מופיעים יומני נתיב, מומלץ לבדוק את ההגדרה של האפליקציה ל-Google Analytics. צריך לעמוד בדרישות הבאות:

הפעלת Google Analytics בפרויקט Firebase.
הפעלתם את שיתוף הנתונים עבור Google Analytics. מידע נוסף על ההגדרה הזו
הוספת את Firebase SDK ל-Google Analytics לאפליקציה. צריך להוסיף את ה-SDK הזה בנוסף ל-Crashlytics SDK.
אתם משתמשים ב גרסאות העדכניות של Firebase SDK לכל המוצרים שבהם אתם משתמשים באפליקציה.

חשוב במיוחד לוודא שאתם משתמשים לפחות בגרסה הבאה של Firebase SDK ל-Google Analytics:
Android – גרסה 17.2.3 ואילך (BoM גרסה 24.7.1 ואילך).

לא רואים התראות על מהירות

אם לא מוצגים לכם התראות על מהירות, ודאו שאתם משתמשים בגרסה Crashlytics SDK v18.6.0+‎ (או Firebase BoM v32.6.0+‎).

לא רואים מדדים לגבי אפליקציות שלא קורסות (או רואים מדדים לא מהימנים)

אם אתם לא רואים מדדים שקשורים לבעיות קריסה (כמו משתמשים וסשנים ללא קריסה) או שאתם רואים מדדים לא מהימנים, כדאי לבדוק את הדברים הבאים:

מוודאים שאתם משתמשים בגרסה הבאה: ‫ Crashlytics SDK v18.6.0+‎ (או Firebase BoM v32.6.0+‎) ‫
חשוב לוודא שהגדרות איסוף הנתונים לא משפיעות על האיכות של מדדי הנתונים ללא קריסה:
- אם מפעילים דיווח על הסכמה על ידי השבתת הדיווח האוטומטי על קריסות, אפשר לשלוח מידע על קריסות אל Crashlytics רק ממשתמשים שהביעו הסכמה מפורשת לאיסוף נתונים. לכן, הדיוק של מדדים שקשורים לקריסות יושפע כי ל-Crashlytics יש מידע על קריסות רק מהמשתמשים שהביעו הסכמה (ולא מכל המשתמשים). המשמעות היא שהמדדים של אפליקציות ללא קריסות עשויים להיות פחות מהימנים ופחות משקפים את היציבות הכוללת של האפליקציה.
- אם השבתתם את איסוף הנתונים האוטומטי, אתם יכולים להשתמש ב-sendUnsentReports כדי לשלוח ל-Crashlytics דוחות שמורים במטמון במכשיר. השימוש בשיטה הזו ישלח נתוני קריסות אל Crashlytics, אבל לא נתוני סשנים, ולכן בתרשימים של המסוף יוצגו ערכים נמוכים או אפס למדדים של קריסות.

איך מחושב שיעור המשתמשים ללא קריסות?

מידע על מדדים של אפליקציות שלא קורסות

למה מקרי ANR מדווחים רק ב-Android 11 ואילך?

‫Crashlytics תומך בדיווח על מקרי ANR באפליקציות ל-Android ממכשירים שפועלת בהם מערכת Android מגרסה 11 ואילך. ממשק ה-API הבסיסי שבו אנחנו משתמשים כדי לאסוף ANR (getHistoricalProcessExitReasons) אמין יותר מגישות שמבוססות על SIGQUIT או על watchdog. ה-API הזה זמין רק במכשירי Android מגרסה 11 ואילך.

למה בחלק מה-ANR חסרים `BuildId`?

אם בחלק מהדוחות על ANR חסר BuildIds, אפשר לנסות לפתור את הבעיה כך:

חשוב לוודא שאתם משתמשים בגרסה עדכנית של Crashlytics Android SDK ושל Crashlytics Gradle plugin.

אם חסרים לכם BuildId ל-Android 11 ולחלק מה-ANR ב-Android 12, סביר להניח שאתם משתמשים ב-SDK, בפלאגין Gradle או בשניהם שהם לא עדכניים. כדי לאסוף BuildId בצורה תקינה עבור שגיאות ANR האלה, צריך להשתמש בגרסאות הבאות:
- ‫Crashlytics Android SDK גרסה ‎18.3.5 ואילך (Firebase BoM גרסה ‎31.2.2 ואילך)
- ‫Crashlytics Gradle plugin v2.9.4+
בודקים אם אתם משתמשים במיקום לא סטנדרטי לספריות המשותפות.

אם חסרים לך רקBuildIds בספריות המשותפות של האפליקציה, סביר להניח שלא השתמשת במיקום הרגיל שמוגדר כברירת מחדל לספריות משותפות. במקרה כזה, יכול להיות שלא תהיה אפשרות לאתר את BuildIds שמשויכים ל-Crashlytics. מומלץ להשתמש במיקום הרגיל לספריות משותפות.
מוודאים שלא מסירים תגי BuildId במהלך תהליך הבנייה.

הערה: הטיפים הבאים לפתרון בעיות רלוונטיים גם ל-ANR וגם לקריסות של אפליקציות מקוריות.
- כדי לבדוק אם קיימים קבצים מסוג BuildId, מריצים את הפקודה readelf -n בקבצים הבינאריים. אם התווים BuildId לא מופיעים, מוסיפים את -Wl,--build-id לסימון של מערכת הבנייה.
- צריך לוודא שלא מסירים בטעות את BuildId כדי להקטין את גודל ה-APK.
- אם שומרים גרסאות stripped וגרסאות unstripped של ספרייה, צריך לוודא שהקוד מצביע על הגרסה הנכונה.

הבדלים בין דוחות ANR בלוח הבקרה Crashlytics לבין דוחות ANR ב-Google Play Console

יכול להיות שיהיה הבדל בין מספר השגיאות מסוג ANR ב-Google Play לבין מספר השגיאות מסוג ANR ב-Crashlytics. התופעה הזו צפויה בגלל ההבדל במנגנון של איסוף נתוני ANR ודיווח עליהם. ‫Crashlytics מדווח על מקרי ANR כשהאפליקציה מופעלת מחדש, בעוד ש'תפקוד האפליקציה' שולח נתוני ANR אחרי שמתרחש ANR.

בנוסף, Crashlytics מציג רק ANR שמתרחשים במכשירים עם Android מגרסה 11 ומעלה, לעומת Google Play שמציג ANR ממכשירים עם Google Play Services והסכמה לאיסוף נתונים.

ההבדלים בין עקבות מחסנית NDK בלוח הבקרה Crashlytics לבין logcat

ל-LLVM ול-GNU toolchains יש הגדרות ברירת מחדל וטיפולים שונים עבור קטע הקריאה בלבד של הקבצים הבינאריים של האפליקציה, מה שיכול ליצור עקבות מחסנית לא עקביים במסוף Firebase. כדי לפתור את הבעיה, מוסיפים את דגלי ה-linker הבאים לתהליך הבנייה:

אם משתמשים ב-lld linker מ-LLVM toolchain, מוסיפים:
```
-Wl,--no-rosegment
```
אם אתם משתמשים במקשר ld.gold מ-GNU toolchain, מוסיפים:
```
-Wl,--rosegment
```

אם עדיין מופיעות אי-התאמות ב-stack trace (או אם אף אחד מהדגלים לא רלוונטי לשרשרת הכלים), אפשר לנסות להוסיף את הפקודה הבאה לתהליך הבנייה:

-fno-omit-frame-pointer

איך משתמשים בקובץ בינארי של מחולל קובצי סמלים של Breakpad משלי ב-NDK?

הפלאגין Crashlytics כולל מחולל קובצי סמלים של Breakpad בהתאמה אישית. אם אתם מעדיפים להשתמש בקובץ בינארי משלכם כדי ליצור קובצי סמלים של Breakpad (לדוגמה, אם אתם מעדיפים ליצור את כל קובצי ההפעלה המקוריים בשרשרת הבנייה שלכם ממקור), אתם יכולים להשתמש במאפיין התוסף האופציונלי symbolGeneratorBinary כדי לציין את הנתיב לקובץ ההפעלה.

אפשר לציין את הנתיב לקובץ הבינארי של מחולל קובצי הסמלים של Breakpad באחת משתי דרכים:

אפשרות 1: ציון הנתיב באמצעות התוסף firebaseCrashlytics בקובץ build.gradle

מוסיפים את השורות הבאות לקובץ build.gradle.kts ברמת האפליקציה:

Gradle plugin v3.0.0+

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")
          }
        }
      }
   }
}

אפשרות 2: ציון הנתיב באמצעות שורת מאפיין בקובץ Gradle.properties

אפשר להשתמש במאפיין com.google.firebase.crashlytics.breakpadBinary כדי לציין את הנתיב לקובץ ההפעלה.

אפשר לעדכן את קובץ המאפיינים של Gradle באופן ידני או לעדכן את הקובץ דרך שורת הפקודה. לדוגמה, כדי לציין את הנתיב באמצעות שורת הפקודה, משתמשים בפקודה כמו זו שבהמשך:
```
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
  -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
  app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
```

לא נתקלת בקריסות עם Dexguard

אם אתם רואים את החריגה הבאה, סביר להניח שאתם משתמשים בגרסה של DexGuard שלא תואמת ל-SDK של Firebase Crashlytics:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

החריגה הזו לא גורמת לקריסת האפליקציה, אבל היא מונעת ממנה לשלוח דוחות קריסה. כדי לפתור את הבעיה:

מוודאים שמשתמשים בגרסה האחרונה של DexGuard 8.x. הגרסה האחרונה כוללת כללים שנדרשים על ידי SDK‏ Firebase Crashlytics.
אם אתם לא רוצים לשנות את הגרסה של DexGuard, נסו להוסיף את השורה הבאה לכללי ההסתרה (בקובץ ההגדרות של DexGuard):
```
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
```

למה אני רואה קריסות מקבצים `.kt` עם התווית `.java` בעיות?

כשמשתמשים באפליקציה במטשטש שלא חושף את סיומת הקובץ, Crashlytics יוצר כל בעיה עם סיומת הקובץ .java כברירת מחדל.

כדי ש-Crashlytics יוכל ליצור בעיות עם סיומת הקובץ הנכונה, צריך לוודא שהאפליקציה משתמשת בהגדרה הבאה:

משתמשים ב-Android Gradle מגרסה 4.2.0 ואילך
משתמש ב-R8 עם הפעלת טשטוש. כדי לעדכן את האפליקציה ל-R8, צריך לפעול לפי ההוראות האלה.

שימו לב: אחרי שתעדכנו את ההגדרה בהתאם לתיאור שלמעלה, יכול להיות שתתחילו לראות .kt בעיות חדשות שהן כפילויות של בעיות קיימות .java. בשאלות הנפוצות אפשר לקרוא מידע נוסף על המקרה הזה.

למה מופיעות `.kt` בעיות שהן כפילויות של בעיות קיימות`.java`?

החל מאמצע דצמבר 2021, Crashlyticsשפרנו את התמיכה באפליקציות שמשתמשות ב-Kotlin.

עד לאחרונה, כלי ההסתרה הזמינים לא חשפו את סיומת הקובץ, ולכן Crashlytics יצר כל בעיה עם סיומת הקובץ .java כברירת מחדל. עם זאת, החל מ-Android Gradle 4.2.0, ‏ R8 תומך בסיומות קבצים.

בעדכון הזה, Crashlytics יכולה לקבוע אם כל מחלקה שנעשה בה שימוש באפליקציה נכתבה ב-Kotlin, ולכלול את שם הקובץ הנכון בחתימת הבעיה. קריסות משויכות עכשיו בצורה נכונה לקבצים מסוג .kt (בהתאם לצורך) אם האפליקציה מוגדרת באופן הבא:

האפליקציה שלכם משתמשת ב-Android Gradle מגרסה 4.2.0 ואילך.
האפליקציה שלך משתמשת ב-R8 עם הפעלת טשטוש.

מאחר שקריסות חדשות כוללות עכשיו את סיומת הקובץ הנכונה בחתימות הבעיה שלהן, יכול להיות שתראו בעיות חדשות עם התווית .kt שהן למעשה כפילויות של בעיות קיימות עם התווית .java. במסוף Firebase, אנחנו מנסים לזהות ולעדכן אתכם אם בעיה חדשה שקשורה ל-.kt היא כפילות אפשרית של בעיה קיימת עם התווית .java.

מי יכול לראות, לכתוב ולמחוק הערות בבעיה?

הערות מאפשרות לחברי הפרויקט להגיב על בעיות ספציפיות עם שאלות, עדכוני סטטוס וכו'.

כשחבר בפרויקט מפרסם הערה, היא מסומנת בכתובת האימייל של חשבון Google שלו. כתובת האימייל הזו גלויה, יחד עם ההערה, לכל חברי הפרויקט שיש להם גישה לצפייה בהערה.

בהמשך מפורטות הרשאות הגישה שנדרשות כדי להציג, לכתוב ולמחוק הערות:

חברי פרויקט עם אחד מהתפקידים הבאים יכולים לראות ולמחוק הערות קיימות ולכתוב הערות חדשות בבעיה.
- בעלים או עורך של הפרויקט, אדמין ב-Firebase, אדמין של איכות, או אדמין של Crashlytics
חברי פרויקט עם אחד מהתפקידים הבאים יכולים לראות את ההערות שפורסמו בבעיה, אבל הם לא יכולים למחוק או לכתוב הערה.
- בעל הרשאת צפייה בפרויקט, בעל הרשאת צפייה ב-Firebase, בעל הרשאת צפייה באיכות או בעל הרשאת צפייה ב-Crashlytics

שילובים

האפליקציה משתמשת גם ב-SDK‏ Google Mobile Ads, אבל לא מתרחשות בה קריסות

אם הפרויקט שלכם משתמש ב-Crashlytics לצד Google Mobile Ads SDK, סביר להניח שדוחות הקריסה מפריעים בזמן רישום המטפלים בחריגים. כדי לפתור את הבעיה, צריך להשבית את הדיווח על קריסות ב-SDK של Mobile Ads באמצעות הקריאה disableSDKCrashReporting.

איפה נמצא מערך הנתונים שלי ב-BigQuery?

אחרי שמקשרים את Crashlytics ל-BigQuery, מערכת Firebase מאתרת באופן אוטומטי את מערכי הנתונים החדשים שיוצרים בארצות הברית, ללא קשר למיקום של פרויקט Firebase.

תמיכה בפלטפורמה

האם Crashlytics תומך ב-armeabi?

‫Firebase Crashlytics NDK לא תומך ב-ARMv5 ‏ (armeabi). התמיכה בממשק ABI הזה הוסרה החל מ-NDK r17.

בעיות שחזרו

מהי בעיה שחלה בה רגרסיה?

בעיה עברה רגרסיה אם סגרתם אותה בעבר, אבל Crashlytics קיבלתם דיווח חדש על כך שהיא חזרה. Crashlytics פותחת מחדש באופן אוטומטי את הבעיות האלה שחזרו, כדי שתוכלו לטפל בהן בהתאם לאפליקציה שלכם.

הנה תרחיש לדוגמה שמסביר איך Crashlytics מסווג בעיה כרגרסיה:

בפעם הראשונה, Crashlytics מקבל דוח קריסה על קריסה מספר A. ‫Crashlytics פותח בעיה תואמת לקריסה (בעיה A).
אתם מתקנים את הבאג הזה במהירות, סוגרים את הבעיה 'א' ומפרסמים גרסה חדשה של האפליקציה.
Crashlytics מקבל דיווח נוסף על בעיה א' אחרי שסגרתם את הבעיה.
- אם הדוח הוא מגרסת אפליקציה ש-Crashlytics ידע עליה כשסגרתם את הבעיה (כלומר, הגרסה שלחה דוח קריסה על כל קריסה שהתרחשה), אז Crashlytics לא יתייחס לבעיה כאל רגרסיה. הבעיה תישאר סגורה.
- אם הדוח הוא מגרסת אפליקציה שCrashlytics לאידעה על הבעיה כשסגרתם אותה (כלומר, הגרסה מעולם לא שלחה אף דוח קריסה לגבי קריסה כלשהי), אז Crashlytics מחשיב את הבעיה כרגרסיה ויפתח אותה מחדש.

אם בעיה חוזרת, אנחנו שולחים התראה על זיהוי רגרסיה ומוסיפים אות רגרסיה לבעיה כדי להודיע לכם ש-Crashlytics פתח מחדש את הבעיה. אם אתם לא רוצים שבעיה תיפתח מחדש בגלל אלגוריתם הרגרסיה שלנו, אתם יכולים להשתיק את הבעיה במקום לסגור אותה.

למה אני רואה בעיות שחזרו בגרסאות קודמות של האפליקציה?

אם הדוח הוא מגרסה ישנה של אפליקציה שמעולם לא שלחה דוחות קריסה כשסגרתם את הבעיה, מערכת Crashlytics תראה שהבעיה חזרה ותפתח אותה מחדש.

מצב כזה יכול לקרות במקרה הבא: תיקנתם באג והשקתם גרסה חדשה של האפליקציה, אבל עדיין יש משתמשים בגרסאות קודמות שלא כוללות את תיקון הבאג. אם במקרה אחת מהגרסאות הקודמות מעולם לא שלחה דוחות קריסה כשסגרתם את הבעיה, והמשתמשים האלה מתחילים להיתקל בבאג, דוחות הקריסה האלה יפעילו בעיה שחזרה.

אם אתם לא רוצים שבעיה תיפתח מחדש בגלל אלגוריתם הרגרסיה שלנו, אתם יכולים להשתיק את הבעיה במקום לסגור אותה.