בדף הזה מפורטת עזרה בפתרון בעיות ותשובות לשאלות נפוצות בנושא השימוש ב-Crashlytics. אם לא מצאתם את מה שחיפשת או אם אתם זקוקים לעזרה נוספת, תוכלו לפנות אל התמיכה של Firebase.
פתרון בעיות כלליות/שאלות נפוצות
פורמטים שונים (ולפעמים 'וריאנטים') של בעיות מסוימות בטבלה בעיות
יכול להיות שתבחינו בשני פורמטים שונים של בעיות שמופיעות בטבלה בעיות במסוף Firebase. יכול להיות שתבחינו גם בתכונה שנקראת 'וריאנטים' בחלק מהבעיות. זו הסיבה!
בתחילת 2023 השקנו מנוע ניתוח משופר לקיבוץ אירועים, עיצוב מעודכן ותכונות מתקדמות לבעיות חדשות (כמו וריאנטים). כל הפרטים מפורטים בפוסט הזה בבלוג, אבל בהמשך מפורטים הדברים העיקריים.
Crashlytics מנתח את כל האירועים מהאפליקציה (כמו קריסות, אירועים לא קטלניים ומקרי ANR) ויוצר קבוצות של אירועים שנקראות בעיות – לכל האירועים בבעיה יש נקודת כשל משותפת.
כדי לקבץ אירועים לבעיות האלה, מנוע הניתוח המשודרג בוחן עכשיו היבטים רבים של האירוע, כולל המסגרות בניתוח סטאק, הודעת החריגה, קוד השגיאה ומאפיינים אחרים של פלטפורמה או של סוג השגיאה.
עם זאת, בתוך קבוצת האירועים הזו, יכול להיות שנתוני מעקב הסטאק שיובילו לכשלים יהיו שונים. אם דוח אחר של נתוני סטאק יהיה שונה, יכול להיות שמדובר בגורם אחר לבעיה.
כדי לייצג את ההבדל האפשרי הזה בתוך בעיה, אנחנו יוצרים עכשיו וריאציות בתוך בעיות – כל וריאנט הוא קבוצת משנה של אירועים בבעיה שיש להם את אותו נקודת כשל וגם נתיב סטאק דומה. בעזרת וריאנטים תוכלו לנפות באגים בנתוני המעקב הנפוצים ביותר בבעיה, ולבדוק אם יש סיבות שונות לבעיה.
אלה השיפורים שתוכלו ליהנות מהם:
מטא-נתונים מעודכנים שמוצגים בשורת הבעיה עכשיו קל יותר להבין את הבעיות באפליקציה ולתעדף אותן.
פחות בעיות כפולות שינוי של מספר שורה לא יוצר בעיה חדשה.
ניפוי באגים קל יותר של בעיות מורכבות עם גורמי שורש שונים אפשר להשתמש בוריאנטים כדי לנפות באגים בנתוני המעקב הנפוצים ביותר בבעיה.
התראות וסמנים משמעותיים יותר בעיה חדשה היא למעשה באג חדש.
חיפוש יעיל יותר כל בעיה מכילה יותר מטא-נתונים שאפשר לחפש, כמו סוג החריגה ושם החבילה.
כך השיפורים האלה ייכנסו לתוקף:
כשנקבל אירועים חדשים מהאפליקציה שלכם, נבדוק אם הם תואמים לבעיה קיימת.
אם לא נמצאה התאמה, נחיל באופן אוטומטי על האירוע את האלגוריתם החכם יותר שלנו לקיבוץ אירועים, ונוצר בעיה חדשה עם העיצוב המחודש של המטא-נתונים.
זהו העדכון המשמעותי הראשון שאנחנו מבצעים לקיבוץ האירועים. אם יש לכם משוב או אם נתקלת בבעיות, אפשר
לשלוח דיווח
.
לא מוצגים מדדים של נסיעות ללא תאונות או התראות על מהירות
אם המדדים של'ללא קריסות' (כמו משתמשים וסשנים ללא קריסות) ו/או ההתראות לגבי מהירות לא מוצגים, צריך לוודא שאתם משתמשים ב-
Crashlytics SDK v18.6.0 ואילך (או Firebase BoM v32.6.0 ואילך).
היומנים של נתיבי הניווט לא מוצגים
אם יומני הלחם לא מופיעים, מומלץ לבדוק את ההגדרות של האפליקציה לגבי Google Analytics.
צריך לעמוד בדרישות הבאות:
חשוב במיוחד לוודא שאתם משתמשים לפחות בגרסת 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?
אם בחלק מה-ANRs חסרים BuildId, פותרים את הבעיה באופן הבא:
חשוב לוודא שאתם משתמשים בגרסה העדכנית של Crashlytics Android SDK ושל Crashlytics הפלאגין של Gradle.
אם חסרים לכם BuildIds ל-Android 11 ולחלק מה-ANRs של Android 12, סביר להניח שאתם משתמשים ב-SDK, בפלאגין של Gradle או בשניהם בגרסה מיושנת.
כדי לאסוף נכסי BuildId בצורה תקינה עבור אירועי ה-ANR האלה, צריך להשתמש בגרסאות הבאות:
בודקים אם אתם משתמשים במיקום לא סטנדרטי לספריות המשותפות.
אם חסרים רק 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 לבין מספר ה-ANR ב-Crashlytics. זה צפוי בגלל ההבדל במנגנון לאיסוף ולדיווח על נתוני ANR. Crashlytics מדווחת על מקרים של ANR כשהאפליקציה מופעלת בפעם הבאה, ואילו Android Vitals שולח נתונים על מקרים של ANR אחרי שהם מתרחשים.
בנוסף, Crashlytics מציג רק אירועי ANR שמתרחשים במכשירים עם Android מגרסה 11 ואילך, לעומת Google Play שמוצגים בו אירועי ANR ממכשירים עם שירותי Google Play והסכמה לאיסוף נתונים.
הבדלים בין מעקב ה-stack של NDK בלוח הבקרה של Crashlytics לבין logcat
ל-LLVM ול-GNU יש ברירת מחדל וטיפולים שונים לקטע לקריאה בלבד של קובצי הבינארי של האפליקציה, שעשויים ליצור מעקבים לא עקביים של סטאק במסוף Firebase. כדי לצמצם את הבעיה, מוסיפים את הדגלים הבאים של הקישור לתהליך ה-build:
אם משתמשים במקשר lld מ-LLVM toolchain, מוסיפים:
-Wl,--no-rosegment
אם משתמשים במקשר ld.gold מ-GNU toolchain, מוסיפים:
-Wl,--rosegment
אם עדיין מופיעות אי-עקביות ב-stack trace (או אם אף אחד מהדגלים לא רלוונטי ל-toolchain שלכם), נסו להוסיף את האפשרות הבאה לתהליך ה-build:
-fno-omit-frame-pointer
איך משתמשים ב-NDK במחולל הבינארי של קובצי הסמלים של Breakpad?
הפלאגין Crashlytics כולל מחולל מותאם אישית של קובץ סמלים של Breakpad.
אם אתם מעדיפים להשתמש בקובץ הבינארי שלכם ליצירת קובצי הסמל של Breakpad (לדוגמה, אם אתם מעדיפים ליצור את כל קובצי ההפעלה הנתמכים בשרשרת ה-build שלכם מהמקור), תוכלו להשתמש במאפיין האפשרי של התוסף symbolGeneratorBinary כדי לציין את הנתיב לקובץ ההפעלה.
אפשר לציין את הנתיב לקובץ הבינארי של ה-generator של קובצי הסמלים של 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 באופן ידני או לעדכן את הקובץ דרך שורת הפקודה. לדוגמה, כדי לציין את הנתיב דרך שורת הפקודה, משתמשים בפקודה כמו זו:
למה אני רואה קריסות מקבצים מסוג .kt שמסומנים כבעיות מסוג .java?
כשאפליקציה משתמשת בתוכנה להסתרת קוד שלא חושפת את סיומת הקובץ, Crashlytics יוצרת כל בעיה עם סיומת הקובץ .java כברירת מחדל.
כדי ש-Crashlytics יוכל ליצור בעיות עם סיומת הקובץ הנכונה, צריך לוודא שהאפליקציה משתמשת בהגדרה הבאה:
שימוש ב-Android Gradle 4.2.0 ואילך
שימוש ב-R8 עם ערפול מופעל. כדי לעדכן את האפליקציה ל-R8, פועלים לפי המסמכים האלה.
שימו לב: אחרי העדכון להגדרה שמתוארת למעלה, יכול להיות שתתחילו לראות בעיות חדשות בנושא .kt שהן כפילויות של בעיות קיימות בנושא .java. מידע נוסף על המצב הזה זמין בשאלות הנפוצות.
למה מוצגות בעיות .kt שהן כפילויות של בעיות .java קיימות?
החל מאמצע דצמבר 2021, Crashlytics שיפר את התמיכה באפליקציות שמשתמשות ב-Kotlin.
עד לאחרונה, התוכנות להסתרת קוד לא חשפו את סיומת הקובץ, ולכן Crashlytics יצר כל בעיה עם סיומת הקובץ .java כברירת מחדל.
עם זאת, החל מגרסה 4.2.0 של Android Gradle, R8 תומך בסיומות קבצים.
בעזרת העדכון הזה, Crashlytics יכול עכשיו לקבוע אם כל הכיתה שבה נעשה שימוש באפליקציה נכתבה ב-Kotlin, ולכלול את שם הקובץ הנכון בחתימת הבעיה. אם האפליקציה שלכם מוגדרת באופן הבא, קריסות משויכות עכשיו בצורה נכונה לקובצי .kt (לפי הצורך):
מאחר שתאונות חדשות כוללות עכשיו את סיומת הקובץ הנכונה בחתימות שלהן, יכול להיות שתראו בעיות חדשות עם התווית .kt שהן למעשה רק כפילויות של בעיות קיימות עם התווית .java. במסוף Firebase אנחנו מנסים לזהות בעיות חדשות ב-.kt שעשויות להיות כפילויות של בעיות קיימות עם התווית .java, ולעדכן אתכם על כך.
מי יכול לראות, לכתוב ולמחוק הערות בבעיה?
הערות מאפשרות למשתתפי הפרויקט להגיב על בעיות ספציפיות, לשאול שאלות, לעדכן את הסטטוס וכו'.
כשחבר בצוות פרויקט מפרסם הערה, היא מסומנת בכתובת האימייל של חשבון Google שלו. כתובת האימייל הזו, יחד עם ההערה, גלויות לכל חברי הפרויקט שיש להם גישה להערה.
הרשאות הגישה הנדרשות כדי להציג, לכתוב ולמחוק הערות:
חברי צוות בפרויקט עם אחד מהתפקידים הבאים יכולים להציג ולמחוק הערות קיימות ולכתוב הערות חדשות בבעיה.
הערות מאפשרות למשתתפי הפרויקט להגיב על בעיות ספציפיות, לשאול שאלות, לעדכן את הסטטוס וכו'.
כשחבר בצוות פרויקט מפרסם הערה, היא מסומנת בכתובת האימייל של חשבון Google שלו. כתובת האימייל הזו, יחד עם ההערה, גלויות לכל חברי הפרויקט שיש להם גישה להערה.
הרשאות הגישה הנדרשות כדי להציג, לכתוב ולמחוק הערות:
חברי צוות בפרויקט עם אחד מהתפקידים הבאים יכולים להציג ולמחוק הערות קיימות ולכתוב הערות חדשות בבעיה.
באפליקציה נעשה שימוש גם ב-SDK של Google Mobile Ads, אבל לא מתרחשות קריסות
אם בפרויקט שלכם נעשה שימוש ב-Crashlytics לצד ה-SDK של Google Mobile Ads, סביר להניח שדיווחי הקריסות מפריעים לרישום של מנהלי החריגות. כדי לפתור את הבעיה, צריך להשבית את הדיווח על קריסות ב-SDK של Mobile Ads באמצעות קריאה ל-disableSDKCrashReporting.
איפה נמצא מערך הנתונים שלי ב-BigQuery?
אחרי שמקשרים את Crashlytics ל-BigQuery, מערכי נתונים חדשים שיצרתם ממוקמים באופן אוטומטי בארצות הברית, ללא קשר למיקום של פרויקט Firebase.
תמיכה בפלטפורמה
האם Crashlytics תומך ב-armeabi?
NDK של Firebase Crashlytics לא תומך ב-ARMv5 (armeabi).
התמיכה ב-ABI הזה הוסרה החל מגרסה NDK r17.
בעיות שחוזרות
מהי בעיה שהתרחשה שוב?
הבעיה חוזרת אם סגרתם אותה בעבר, אבל Crashlytics מקבל דיווח חדש על כך שהבעיה חוזרת.
Crashlytics פותח מחדש באופן אוטומטי את הבעיות האלה כדי שתוכלו לטפל בהן בהתאם לאפליקציה שלכם.
הנה תרחיש לדוגמה שמסביר איך Crashlytics מסווג בעיה כרגרסיה:
בפעם הראשונה, Crashlytics מקבל דוח קריסה לגבי 'תאונה א'. Crashlytics פותח בעיה תואמת לקריסה הזו (בעיה 'א').
אתם מתקנים את הבאג במהירות, סוגרים את הבעיה 'א' ומפיצים גרסה חדשה של האפליקציה.
Crashlytics מקבל דיווח נוסף על בעיה 'א' אחרי שסגרתם את הבעיה.
אם הדוח מגיע מגרסה של האפליקציה ש-Crashlyticsידעה עליה כשסגרתם את הבעיה (כלומר, הגרסה שלחה דוח קריסה לגבי כל קריסה), Crashlytics לא תתייחס לבעיה כאל חזרה לאחור. הבעיה תישאר סגורה.
אם הדוח מגיע מגרסה של האפליקציה ש-Crashlyticsלא ידעה עליה כשסגרתם את הבעיה (כלומר, הגרסה אף פעם לא שלחה אף דוח קריסה לגבי קריסה כלשהי), Crashlytics תתייחס לבעיה כאל חזרה לאחור ותפתח מחדש את הבעיה.
כשבעיה חוזרת, אנחנו שולחים התראה על זיהוי רגרסיה ומוסיפים לבעיה אות רגרסיה כדי להודיע לכם ש-Crashlytics פתח אותה מחדש. אם אתם לא רוצים שהבעיה תיפתח מחדש בגלל אלגוריתם הרגרסיה שלנו, תוכלו להשתיק את הבעיה במקום לסגור אותה.
למה אני רואה בעיות בגרסאות ישנות יותר של האפליקציה?
אם הדיווח מגיע מגרסה ישנה של האפליקציה שמעולם לא שלחה דוחות קריסה בכלל כשסגרתם את הבעיה, Crashlytics תתייחס לבעיה כאל חזרה לאחור ותפתח אותה מחדש.
המצב הזה יכול לקרות במצב הבא: תיקנתם באג ושחררתם גרסה חדשה של האפליקציה, אבל עדיין יש משתמשים בגרסאות ישנות יותר של האפליקציה בלי תיקון הבאג. אם במקרה אחת מהגרסאות הישנות האלה אף פעם לא שלחה דוחות קריסה כשסגרתם את הבעיה, והמשתמשים האלה מתחילים להיתקל בבאג, דוחות הקריסה האלה יגרמו לבעיה של נסיגה לאחור.
אם אתם לא רוצים שהבעיה תיפתח מחדש בגלל אלגוריתם הרגרסיה שלנו, תוכלו להשתיק אותה במקום לסגור אותה.
