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

לא רואה משתמשים ללא קריסה, יומני פירורי לחם ו/או התראות מהירות

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

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

• ודא ששיתוף נתונים מופעל עבור Google Analytics בדף אינטגרציות > Google Analytics של מסוף Firebase. שים לב שהגדרות שיתוף הנתונים מוצגות במסוף Firebase אך מנוהלות במסוף של Google Analytics.

• בנוסף ל- Firebase Crashlytics SDK, ודא שהוספת את Firebase SDK עבור Google Analytics לאפליקציה שלך ( iOS+ | Android ).

• ודא שאתה משתמש בגרסאות העדכניות ביותר עבור כל ערכות Firebase שלך ​​( iOS+ | Android ).
  בדוק במיוחד שאתה משתמש לפחות בגרסאות הבאות של Firebase SDK עבור Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ עבור macOS ו-tvOS) | אנדרואיד - v17.2.3+ (BoM v24.7.1+) .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מדוע מדווחים על מקרי ANR רק עבור Android 11+?

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

מדוע חלק מה-ANR חסרים את s BuildId שלהם?

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

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

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

  • Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
  • תוסף Crashlytics Gradle v2.9.4+

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

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

• ודא שאינך מסיר BuildId במהלך תהליך הבנייה.

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

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

  • בדוק שאינך מסיר בטעות את רכיבי BuildId במאמץ להקטין את גודל ה-APK שלך.

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

הבדלים בין דוחות ANR במרכז השליטה של ​​Crashlytics לבין Google Play Console

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

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

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

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

• אם אתה משתמש במקשר lld משרשרת הכלים של LLVM, הוסף:

  -Wl,--no-rosegment
  

• אם אתה משתמש במקשר ld.gold משרשרת הכלים של GNU, הוסף:

  -Wl,--rosegment
  

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

-fno-omit-frame-pointer

כיצד אוכל להשתמש במחולל קבצי סמלים Breakpad בינארי עבור NDK?

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

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

• אפשרות 1 : ציין את הנתיב דרך סיומת firebaseCrashlytics בקובץ build.gradle שלך

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

  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.symbolGeneratorBinary כדי לציין את הנתיב לקובץ ההפעלה.

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

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

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

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

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.

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

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

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

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

כיצד מחושבים משתמשים ללא קריסה?

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

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

CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100

• כאשר מתרחשת קריסה, Google Analytics שולח סוג אירוע app_exception , ו- CRASHED_USERS מייצג את מספר המשתמשים המשויכים לסוג האירוע הזה.

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

אחוז המשתמשים ללא קריסות הוא צבירה לאורך זמן , לא ממוצע.

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

• ביום רביעי, אחוז המשתמשים ללא קריסות שלך הוא 50% (1 מכל 2 משתמשים היה ללא קריסות).
  שניים מהמשתמשים שלך עסקו באפליקציה שלך ביום רביעי, אבל רק לאחד מהם (משתמש B) לא היו קריסות.

• במשך היומיים האחרונים, אחוז המשתמשים ללא קריסות שלך הוא 33.3% (1 מתוך 3 משתמשים היה ללא קריסות).
  שלושה מהמשתמשים שלך היו מעורבים באפליקציה שלך במהלך היומיים האחרונים, אבל רק לאחד מהם (משתמש C) לא היו קריסות.

• במשך 3 הימים האחרונים, אחוז המשתמשים ללא קריסות שלך הוא 0% (0 מתוך 3 משתמשים היו ללא קריסות).
  שלושה מהמשתמשים שלך היו מעורבים באפליקציה שלך במהלך שלושת הימים האחרונים, אבל לאפס מהם לא היו קריסות.

מי יכול להציג, לכתוב ולמחוק הערות בנושא?

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

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

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

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

  • בעל פרויקט או עורך , מנהל Firebase , מנהל איכות או מנהל מערכת Crashlytics

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

  • Project Viewer , Firebase Viewer , Quality Viewer או Crashlytics Viewer

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

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

היכן נמצא מערך הנתונים של BigQuery שלי?

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

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

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

מהי בעיה שנסוגה?

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

להלן תרחיש לדוגמה המסביר כיצד Crashlytics מסווג בעיה כרגרסיה:

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

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

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

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

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

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