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

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

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

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

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

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

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

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

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

• פחות בעיות כפולות
  שינוי של מספר השורה לא מוביל ליצירת בעיה חדשה.

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

• התראות וסמנים משמעותיים יותר
  בעיה חדשה היא בעצם באג חדש.

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

כך השיפורים האלה ייכנסו לתוקף:

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

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

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

לא מוצגים מדדים של נסיעות ללא תאונות או התראות על מהירות

אם המדדים של 'ללא קריסות' (כמו משתמשים וסשנים ללא קריסות) ו/או ההתראות לגבי מהירות לא מוצגים, צריך לוודא שאתם משתמשים ב- Crashlytics SDK v18.6.0 ואילך (או Firebase BoM v32.6.0 ואילך).

היומנים של נתיבי הניווט לא מוצגים

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

• הפעלתם את Google Analytics בפרויקט Firebase.

• הפעלתם את האפשרות שיתוף נתונים בחשבון Google Analytics. מידע נוסף על ההגדרה הזו זמין במאמר ניהול של הגדרות שיתוף הנתונים מ-Analytics

• הוספת Firebase SDK ל-Google Analytics לאפליקציה. צריך להוסיף את ה-SDK הזה בנוסף ל-SDK של Crashlytics.

• אתם משתמשים ב הגרסאות האחרונות של Firebase SDK בכל המוצרים שבהם אתם משתמשים באפליקציה.

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

למה דיווח על מקרי ANR מתבצע רק לגבי Android מגרסה 11 ואילך?

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

למה בחלק מהאירועים של 'לא ניתן להציג את המודעה' חסרים BuildId?

אם בחלק מהאירועים של ANR חסרים BuildId, פותרים את הבעיה באופן הבא:

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

  אם חסרים לכם BuildIds ל-Android 11 ולחלק מה-ANRs של Android 12, סביר להניח שאתם משתמשים ב-SDK, בפלאגין של Gradle או בשניהם בגרסה מיושנת. כדי לאסוף נכסי BuildId בצורה תקינה עבור אירועי ה-ANR האלה, צריך להשתמש בגרסאות הבאות:

  • Crashlytics Android SDK מגרסה 18.3.5 ואילך (Firebase BoM מגרסה 31.2.2 ואילך)
  • Crashlytics פלאגין Gradle מגרסה 2.9.4 ואילך

• בודקים אם אתם משתמשים במיקום לא סטנדרטי לספריות המשותפות.

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

• חשוב לוודא שלא מסירים את ה-BuildId במהלך תהליך ה-build.

  שימו לב שהטיפים הבאים לפתרון בעיות רלוונטיים גם למקרי ANR וגם לקריסות מקוריות.

  • כדי לבדוק אם קובצי ה-BuildId קיימים, מריצים את readelf -n בקובצי ה-binary. אם הערכים של BuildId לא מופיעים, צריך להוסיף את הערך -Wl,--build-id לדגלים של מערכת ה-build.

  • חשוב לוודא שאתם לא מסירים בטעות את ה-BuildIds בניסיון לצמצם את גודל ה-APK.

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

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

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

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

הבדלים בין מעקב ה-stack של NDK בלוח הבקרה של Crashlytics לבין logcat

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

• אם משתמשים במקשר lld מ-LLVM toolchain, מוסיפים:

  -Wl,--no-rosegment

• אם משתמשים במקשר ld.gold מ-GNU toolchain, מוסיפים:

  -Wl,--rosegment

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

-fno-omit-frame-pointer

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

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

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

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

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

  פלאגין Gradle מגרסה 3.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

  אפשר להשתמש בנכס 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

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

1. חשוב לוודא שאתם משתמשים בגרסה האחרונה של DexGuard 8.x. הגרסה האחרונה מכילה כללים שנדרשים על ידי Firebase Crashlytics SDK.

2. אם אתם לא רוצים לשנות את גרסת 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.

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

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

• באפליקציה שלך נעשה שימוש ב-Android Gradle מגרסה 4.2.0 ואילך.
• באפליקציה שלך נעשה שימוש ב-R8 עם ערפול קוד (obfuscation).

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

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

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

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

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

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

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

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

  • צפייה בפרויקט, צפייה ב-Firebase, צפייה בנתוני איכות או צפייה ב-Crashlytics

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

הסבר על מדדים ללא קריסות

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

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

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

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

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

  • בעלים או עריכה בפרויקט, אדמין ב-Firebase, אדמין איכות או אדמין Crashlytics

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

  • צפייה בפרויקט, צפייה ב-Firebase, צפייה בנתוני איכות או צפייה ב-Crashlytics

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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