‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

בדף הזה מופיע מידע על סוגי הנושאים הבאים:

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

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

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

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

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

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

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

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

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

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

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

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

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

יומני פעולות משתמש לא מוצגים

אם לא מופיעים יומני נתיב (breadcrumb) (iOS+‎ | Android | Flutter | Unity), מומלץ לבדוק את ההגדרה של Google Analytics באפליקציה. צריך לעמוד בדרישות הבאות:

הפעלת Google Analytics בפרויקט Firebase.
הפעלתם את שיתוף הנתונים עבור Google Analytics. מידע נוסף על הגדרה זו בהרשאות שיתוף נתונים של Analytics
הוספת לאפליקציה את Firebase SDK ל-Google Analytics: iOS+‎ | Android | Flutter | Unity.
צריך להוסיף את ה-SDK הזה בנוסף ל-Crashlytics SDK.
אתם משתמשים בגרסאות העדכניות של Firebase SDK לכל המוצרים שבהם אתם משתמשים באפליקציה שלכם (iOS+‎ |‏ Android |‏ Flutter |‏ Unity).

בפלטפורמות של אפל ובאפליקציות ל-Android, חשוב במיוחד לוודא שאתם משתמשים לפחות בגרסה הבאה של Firebase SDK ל-Google Analytics: ‫iOS+‎ – גרסה 6.3.1 ואילך (גרסה 8.9.0 ואילך ל-macOS ול-tvOS) | ‫Android – גרסה 17.2.3 ואילך (BoM גרסה 24.7.1 ואילך).

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

אם לא מוצגים לכם התראות על מהירות, ודאו שאתם משתמשים בגרסה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תמיכה ספציפית לפלטפורמה

בקטעים הבאים מפורטות תשובות לשאלות נפוצות ופתרונות לבעיות שקשורות לפלטפורמות ספציפיות: iOS+‎ | Android | Unity.

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

חסרים קובצי dSYM או שהם לא מועלים

כדי להעלות את קובצי ה-dSYM של הפרויקט ולקבל פלט מפורט, צריך לבדוק את הדברים הבאים:

מוודאים ששלב ה-build של הפרויקט מכיל את Crashlytics run script, שמאפשר ל-Xcode להעלות את קובצי ה-dSYM של הפרויקט בזמן ה-build (הוראות להוספת הסקריפט מופיעות במאמר Initializing Crashlytics). אחרי העדכון של הפרויקט, מכריחים קריסה ומוודאים שהקריסה מופיעה בלוח הבקרה Crashlytics.
אם מופיעה התראה 'חסר dSYM' במסוף Firebase, צריך לבדוק ב-Xcode כדי לוודא שנוצרים קובצי dSYM בצורה תקינה עבור הגרסה.
אם Xcode יוצר קובצי dSYM כמו שצריך, ואתם עדיין רואים קובצי dSYM חסרים, סביר להניח שכלי הסקריפט נתקע בזמן העלאת קובצי ה-dSYM. במקרה כזה, נסו לבצע את הפעולות הבאות:
- מוודאים שמשתמשים בגרסה העדכנית ביותר של Crashlytics.
- מעלים את קובצי ה-dSYM החסרים באופן ידני:
  - אפשרות 1: משתמשים באפשרות 'גרירה ושחרור' מבוססת-המסוף בכרטיסייה dSYMs כדי להעלות ארכיון ZIP שמכיל את קובצי ה-dSYM החסרים.
  - אפשרות 2: משתמשים בסקריפט upload-symbols כדי להעלות את קובצי ה-dSYM החסרים, עבור ה-UUID שסופק בכרטיסייה dSYMs.
אם עדיין חסרים קובצי dSYM או שההעלאות עדיין לא מצליחות, צריך לפנות אל התמיכה של Firebase ולצרף את היומנים.

הקריסות לא מסומלות בצורה טובה

אם נראה שהסמלים ב-stack traces לא תקינים, כדאי לבדוק את הדברים הבאים:

אם לפריים בספרייה של האפליקציה אין הפניות לקוד של האפליקציה, צריך לוודא ש--fomit-frame-pointer לא מוגדר כדגל קומפילציה.
אם מופיעים כמה (Missing) פריימים לספרייה של האפליקציה, בודקים אם יש קובצי dSYM אופציונליים שמופיעים כחסרים (לגרסת האפליקציה המושפעת) בכרטיסייה Crashlytics dSYMs במסוף Firebase. אם כן, צריך לפעול לפי השלב לפתרון בעיות שמופיע בקטע שאלות נפוצות בנושא קובצי dSYM חסרים או שלא מועלים בדף הזה. שימו לב: העלאת קובצי ה-dSYM האלה לא תבצע סימבוליזציה של קריסות שכבר התרחשו, אבל היא תעזור להבטיח סימבוליזציה של קריסות עתידיות.

אפשר להשתמש ב-Crashlytics ב-macOS או ב-tvOS?

כן, אפשר להטמיע את Crashlytics בפרויקטים של macOS ו-tvOS. חשוב לוודא שאתם כוללים את גרסה 8.9.0 ואילך של Firebase SDK עבור Google Analytics, כדי שלקריסות תהיה גישה למדדים שנאספים על ידי Google Analytics (משתמשים ללא קריסות, הגרסה האחרונה, התראות על מהירות ויומני נתוני מיקום).

האם אפשר להשתמש ב-Crashlytics בפרויקט Firebase עם כמה אפליקציות בפלטפורמות שונות של Apple?

עכשיו אפשר לדווח על קריסות של כמה אפליקציות בפרויקט Firebase אחד, גם אם האפליקציות מיועדות לפלטפורמות שונות של Apple (לדוגמה, iOS,‏ tvOS ו-Mac Catalyst). בעבר, אם לאפליקציות היה אותו מזהה חבילה, הייתם צריכים להפריד אותן לפרויקטים נפרדים ב-Firebase.

תמיכה ב-Android

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

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

למה בחלק מה-ANR לא מופיע `BuildId`?

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

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

אם חסרים לכם BuildIds ל-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 בספריות המשותפות של האפליקציה, סביר להניח שלא השתמשתם במיקום הרגיל שמוגדר כברירת מחדל לספריות משותפות. אם זה המצב, יכול להיות ש-Crashlytics לא יוכל לאתר את BuildId המשויכים. מומלץ להשתמש במיקום הסטנדרטי לספריות משותפות.
מוודאים שלא מסירים תגי BuildId במהלך תהליך build.

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

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

יכול להיות שיהיה הבדל בין מספר שגיאות ה-ANR ב-Google Play לבין המספר ב-Crashlytics. ההבדל הזה צפוי בגלל ההבדל במנגנון של איסוף נתוני ANR ודיווח עליהם. ‫Crashlytics reports ANRs when the app next starts up, whereas Android Vitals sends ANR data after the ANR occurs.

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

למה אני רואה קריסות מקובצי `.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.

לא נתקלים בקריסות עם 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
```

איך משדרגים לגרסה 3 של הפלאגין Crashlytics Gradle

הגרסה האחרונה של Crashlytics Gradle plugin היא גרסה מרכזית (v3.0.0) והיא מודרנית יותר כי היא לא תומכת בגרסאות ישנות יותר של Gradle ושל פלאגין של Android Gradle. בנוסף, השינויים בגרסה הזו פותרים בעיות ב-AGP מגרסה 8.1 ואילך, ומשפרים את התמיכה באפליקציות Native ובגרסאות Build בהתאמה אישית.

דרישות מינימליות

לפלאגין Crashlytics Gradle v3 יש את דרישות המינימום הבאות:

‫Android Gradle plugin 8.1+
כדי לשדרג את פלאגין של Android Gradle הזה, משתמשים בAndroid Gradle plugin Upgrade Assistant בגרסה העדכנית ביותר של Android Studio.
‫google-services Gradle plugin 4.4.1+‎
של Firebase כדי לשדרג את הפלאגין הזה, צריך לציין את הגרסה העדכנית בקובץ ה-build של Gradle בפרויקט, באופן הבא:

Kotlin

plugins {
  id("com.android.application") version "8.1.4" apply false
  id("com.google.gms.google-services") version "4.5.0" apply false
  ...
}

Groovy

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.5.0' apply false
  ...
}

שינויים בתוסף Crashlytics

בגרסה 3 של Crashlytics Gradle plugin, יש בתוסף Crashlytics את שינויי התוכנה הבאים שעלולים לגרום לכשל:

הסרנו את התוסף מהבלוק defaultConfig android. במקום זאת, צריך להגדיר כל וריאנט.
הוסר השדה שיצא משימוש mappingFile. במקום זאת, קובץ המיפוי הממוזג מסופק עכשיו באופן אוטומטי.
הוסר השדה שיצא משימוש strippedNativeLibsDir. במקום זאת, צריך להשתמש ב-unstrippedNativeLibsDir לכל הספריות המקוריות.

השדה unstrippedNativeLibsDir השתנה והפך לשדה מצטבר.

דוגמה עם כמה ספריות

buildTypes {
  release {
    configure<CrashlyticsExtension> {
      nativeSymbolUploadEnabled = true
      unstrippedNativeLibsDir = file("MY/NATIVE/LIBS")
    }
  }
  productFlavors {
    flavorDimensions += "feature"
    create("basic") {
      dimension = "feature"
      // ...
    }
    create("featureX") {
      dimension = "feature"
      configure<CrashlyticsExtension> {
        unstrippedNativeLibsDir = file("MY/FEATURE_X/LIBS")
      }
    }
  }
}

המשימה uploadCrashlyticsSymbolFilesBasicRelease תעלה רק את הסמלים ב-MY/NATIVE/LIBS, אבל המשימה uploadCrashlyticsSymbolFilesFeatureXRelease תעלה את הסמלים גם ב-MY/NATIVE/LIBS וגם ב-MY/FEATURE_X/LIBS.

החלפנו את שדה הסגירה symbolGenerator בשני שדות חדשים ברמה העליונה:
- ‫symbolGeneratorType, מחרוזת של "breakpad" (ברירת מחדל) או "csym".
- ‫breakpadBinary, קובץ של dump_syms בינארי מקומי שמוגדר כברירת מחדל.

דוגמה לשדרוג התוסף

Kotlin

לפני

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGenerator(
                closureOf<SymbolGenerator> {
                  symbolGeneratorType = "breakpad"
                  breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              )
            }
          }
        }

עכשיו בגרסה 3

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGeneratorType = "breakpad"
              breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }

Groovy

לפני

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGenerator {
                breakpad {
                  binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              }
            }
          }
        }

עכשיו בגרסה 3

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }

תמיכה ספציפית ל-Android-NDK

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

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

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

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

-fno-omit-frame-pointer

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

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

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

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

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

גרסה 3.0.0 ואילך של Gradle Plugin

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
```

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

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

תמיכה ב-Unity

הצגת עקבות מחסנית (stack traces) לא מסומלים של אפליקציות ל-Android בלוח הבקרה Crashlytics

אם אתם משתמשים ב-Unity IL2CPP ואתם רואים מעקבי מחסנית לא מסומלים, נסו את הפעולות הבאות:

מוודאים שאתם משתמשים בגרסה v8.6.1 ואילך של Crashlytics Unity SDK.
מוודאים שהגדרתם את הפקודה Firebase ב-CLI של crashlytics:symbols:upload ושהיא פועלת כדי ליצור ולהעלות את קובץ הסמלים.

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

האם אפשר להשתמש ב-Crashlytics עם אפליקציות שמשתמשות ב-IL2CPP?

כן, Crashlytics יכול להציג עקבות מחסנית עם סימבולים לאפליקציות שמשתמשות ב-IL2CPP. היכולת הזו זמינה באפליקציות שפורסמו בפלטפורמות Android או Apple. כך עושים זאת:

מוודאים שאתם משתמשים בגרסה 8.6.0 ואילך של Crashlytics Unity SDK.
משלימים את המשימות הנדרשות לפלטפורמה:
- באפליקציות לפלטפורמת Apple: לא נדרשות פעולות מיוחדות. באפליקציות לפלטפורמת Apple, התוסף Firebase Unity Editor מגדיר באופן אוטומטי את פרויקט Xcode להעלאת סמלים.
- באפליקציות ל-Android: מוודאים שהגדרתם את הפקודה Firebase CLI crashlytics:symbols:upload והיא פועלת כדי ליצור ולהעלות את קובץ הסמלים.
  
  צריך להריץ את פקודת ה-CLI הזו בכל פעם שיוצרים גרסת build של מהדורה או כל גרסת build שרוצים לראות בה עקבות מחסנית עם סימבולים במסוף Firebase. מידע נוסף על קבלת דוחות קריסה קריאים

דיווח על חריגים שלא זוהו כשגיאות חמורות

‫Crashlytics יכול לדווח על חריגים שלא נתפסו כשגיאות קריטיות (החל מגרסה v10.4.0 של Unity SDK). בקטע השאלות הנפוצות הבא מוסבר ההיגיון מאחורי התכונה הזו ומוצגות שיטות מומלצות לשימוש בה.

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

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

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

אילו חריגים ידווחו כשגיאות חמורות?

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

במהלך ההפעלה באפליקציה, צריך להגדיר את המאפיין ReportUncaughtExceptionsAsFatal לערך true.
האפליקציה שלך (או ספרייה שכלולה בה) יוצרת חריגה שלא נתפסת. חריג שנוצר, אבל לא מופעל, לא נחשב כחריג שלא נתפס.

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

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

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

איך לזהות חריגים שנוצרו ולטפל בהם

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

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

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

רישום חריגים ב-Unity או ב-Crashlytics

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

כשמשתמשים ב-Crashlytics, אלה שתי האפשרויות הכי נפוצות ומומלצות:

אפשרות 1: הדפסה במסוף Unity, אבל לא דיווח ל-Crashlytics, במהלך פיתוח או פתרון בעיות
- הדפסה למסוף Unity באמצעות Debug.Log(exception),‏ Debug.LogWarning(exception) ו-Debug.LogError(exception), שמדפיסים את תוכן החריגה למסוף Unity ולא מעבירים מחדש את החריגה.
אפשרות 2: העלאה אל Crashlytics ליצירת דוחות מאוחדים בלוח הבקרה של Crashlytics במקרים הבאים:
- אם חריגה מצדיקה רישום ביומן כדי לנפות באגים באירוע Crashlytics אפשרי שיתרחש בהמשך, צריך להשתמש ב-Crashlytics.Log(exception.ToString()).
- אם רוצים שחריג מסוים ידווח ל-Crashlytics למרות שהוא נתפס ומטופל, אפשר להשתמש ב-Crashlytics.LogException(exception) כדי לרשום אותו כאירוע לא קריטי.

עם זאת, אם רוצים לדווח באופן ידני על אירוע קריטי ל-Unity Cloud Diagnostics, אפשר להשתמש ב-Debug.LogException. האפשרות הזו מדפיסה את החריג במסוף Unity כמו באפשרות 1, אבל היא גם יוצרת את החריג (בין אם הוא נוצר או נתפס ובין אם לא). השגיאה מופיעה לא באופן מקומי. כלומר, גם אם מקיפים את Debug.LogException(exception) בבלוקים של try-catch, עדיין תתקבל חריגה שלא נתפסה.

לכן, צריך להתקשר אל Debug.LogException רק אם רוצים לבצע את כל הפעולות הבאות:

כדי להדפיס את החריגה במסוף Unity.
כדי להעלות את החריגה אל Crashlytics כאירוע קריטי.
כדי להפעיל את החריגה, צריך להתייחס אליה כאל חריגה לא מטופלת ולדווח עליה ל-Unity Cloud Diagnostics.

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

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}

תמיכה בשילובים

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

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

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

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

המיקום הזה חל גם על קבוצת הנתונים Crashlytics וגם על קבוצת הנתונים של הסשנים ב-Firebase (אם הופעל ייצוא של נתוני סשנים).
המיקום הזה רלוונטי רק לנתונים שמיוצאים אל BigQuery, והוא לא משפיע על מיקום הנתונים שמאוחסנים לשימוש בלוח הבקרה Crashlytics במסוף Firebase או ב-Android Studio.
אי אפשר לשנות את המיקום של מערך הנתונים אחרי שיוצרים אותו, אבל אפשר להעתיק את מערך הנתונים למיקום אחר או להעביר אותו ידנית (ליצור אותו מחדש) למיקום אחר. מידע נוסף מופיע במאמר שינוי המיקום של ייצוא קיים.

נתקלתם בבעיות אחרי ששדרגתם לתשתית הייצוא החדשה של BigQuery?

באמצע אוקטובר 2024, Crashlytics השיק תשתית חדשה לייצוא אצווה של נתוני Crashlytics אל BigQuery.

החל מ-2 במרץ 2026, כל הפרויקטים ב-Firebase שודרגו אוטומטית לתשתית החדשה של ייצוא באצ'ים.

ההבדלים החשובים בין תשתית הייצוא הישנה לבין תשתית הייצוא החדשה

התשתית החדשה תומכת Crashlytics במיקומים של מערכי נתונים מחוץ לארצות הברית.
- הפעלתם ייצוא לפני אמצע אוקטובר 2024 ושדרגתם לתשתית הייצוא החדשה – עכשיו יש לכם אפשרות לשנות את המיקום לייצוא הנתונים.
- הייצוא הופעל באמצע אוקטובר 2024 או מאוחר יותר – במהלך ההגדרה הוצגה לכם בקשה לבחור מיקום לייצוא הנתונים.
התשתית החדשה לא תומכת בהוספה של נתונים מהתקופה שלפני שהפעלתם את הייצוא.
- במערכת הישנה, מילוי החוסרים (backfill) היה אפשרי עד 30 ימים לפני התאריך שבו הפעלתם את הייצוא.
- התשתית החדשה תומכת במילוי חוסרים עד 30 ימים אחורה או עד התאריך האחרון שבו הפעלתם את הייצוא אל BigQuery (התאריך המאוחר מביניהם).
השמות של הטבלאות החדשות בתשתית הם BigQuery batch tables, והם מבוססים על המזהים שהוגדרו לאפליקציות Firebase בפרויקט Firebase.
- בתשתית הישנה, הנתונים נכתבו לטבלאות של קבוצות עם שמות שמבוססים על מזהי החבילות או שמות החבילות בבינארי של האפליקציה.
- במסגרת התשתית החדשה, הנתונים נכתבים לטבלאות של מנות (batch) עם שמות שמבוססים על מזהי החבילות או על שמות החבילות שמוגדרים לאפליקציות Firebase הרשומות בפרויקט Firebase.

אם השם של טבלת האצווה הקודמת לא תאם למזהה האפליקציה ב-Firebase

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

הסבר על האופן שבו מזהים משמשים את תשתית הייצוא לכתיבת נתונים בטבלאות BigQuery

כך שתי התשתיות לייצוא כותבות נתוני Crashlytics לטבלאות של מנות:BigQuery

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

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

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

אם המזהים בשני המקומות האלה לא זהים, סימן שקרה אחד מהדברים הבאים:

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

תרחישים לדוגמה של מזהים לא תואמים

שימו לב: לשמות של טבלאות של קבוצות של אפליקציות מצורף באופן אוטומטי BigQuery_IOS או _ANDROID כדי לציין את הפלטפורמה של האפליקציה.

מזהים בבינארי של האפליקציה	מזהים שהוגדרו לאפליקציות שלכם ב-Firebase	התנהגות קודמת	התנהגות אחרי שדרוג לתשתית הייצוא החדשה	פתרון
`foo`	`bar`	הכתיבה מתבצעת לטבלה אחת שנקראת על שם המזהה בקובץ הבינארי של האפליקציה (`foo`)	יוצרת ואז כותבת לטבלה אחת שנקראת על שם המזהה שהוגדר לאפליקציה ב-Firebase‏ (`bar`)	מטמיעים את אפשרות 1 או את אפשרות 2 שמתוארות בהמשך.
`foo`	‫`bar`, `qux` וכו'.	הכתיבה מתבצעת לטבלה אחת שנקראת על שם המזהה בקובץ הבינארי של האפליקציה (`foo`)	יוצר* ואז כותב לכמה טבלאות שנקראות על שם המזהים שמוגדרים לאפליקציות Firebase (`bar`,‏ `qux` וכו')	מיישמים את אפשרות 2 שמתוארת בהמשך.
‫`foo`, `baz` וכו'.	`bar`	כותבת לכמה טבלאות שנקראות על שם כמה מזהים בבינארי של האפליקציה (`foo`, `baz` וכו')	יוצר** ואז כותב את הנתונים של כל אפליקציה לטבלה אחת שנקראת על שם המזהה שהוגדר לאפליקציית Firebase ‏ (`bar`)	אי אפשר להטמיע אף אחת מהאפשרויות. עדיין אפשר להבחין בין הנתונים של כל אפליקציה בטבלה אחת באמצעות `bundle_identifier` של האפליקציה, שמיוצא לצד הנתונים.

^{* אם המזהה בבינארי של האפליקציה תאם לאחד מהמזהים שהוגדרו לאפליקציית Firebase, התשתית החדשה של הייצוא לא יצרה טבלה חדשה למזהה הזה. במקום זאת, הוא ימשיך לכתוב נתונים לאפליקציה הספציפית הזו. כל שאר האפליקציות ייכתבו לטבלאות חדשות.}

^{** אם אחד מהמזהים בקובץ הבינארי של האפליקציה תאם למזהה שהוגדר לאפליקציית Firebase, התשתית החדשה של הייצוא לא יצרה טבלה חדשה. במקום זאת, המערכת תשמור את הטבלה ותתחיל לכתוב בה נתונים מכל האפליקציות.}

אפשרויות לצמצום ההפרעה

אפשרות 1:
שימוש בטבלה החדשה שנוצרה על ידי תשתית הייצוא החדשה. תעתיקו את הנתונים מהטבלה הקודמת לטבלה החדשה.
1. במסוף Google Cloud, מעתיקים את כל הנתונים מהטבלה הקודמת לטבלה החדשה שנוצרה במהלך שדרוג התשתית.
2. אם יש לכם תלות במורד הזרם שמתבססת על טבלת האצווה, צריך לשנות אותה כך שתתבסס על הטבלה החדשה.
הערה: נתונים חדשים לא ייכתבו לטבלה מדור קודם. כל הנתונים שנכתבו בעבר בטבלה מדור קודם לא יימחקו.
אפשרות 2:
הגדרה מחדש של הכתיבה לטבלה הקודמת. כדי לעשות את זה, צריך לשנות כמה הגדרות ברירת מחדל בקובץ ההגדרות של BigQuery.
1. במסוף Firebase, מאתרים את מזהה האפליקציה ב-Firebase (לדוגמה, 1:1234567890:ios:321abc456def7890) של האפליקציה עם שם הטבלה ומזהה האצווה שלא תואמים ורושמים אותו:
  עוברים אל Project settings (הגדרות הפרויקט), ואז אל הכרטיס Your apps (האפליקציות שלך) כדי לראות את כל האפליקציות ב-Firebase והמידע שלהן.
2. במסוף Google Cloud, משנים את ההגדרה החדשה של העברת הנתונים שנוצרה בעקבות שדרוג התשתית, כך שהנתונים ייכתבו לטבלה מדור קודם:
  1. עוברים אל BigQuery > העברות נתונים כדי לראות את 'הגדרת העברת הנתונים'.
  2. בוחרים את ההגדרה שכוללת את המקור Firebase Crashlytics with Multi-Region Support.
  3. לוחצים על עריכה בפינה השמאלית העליונה.
  4. בקטע פרטים של מקור הנתונים, מאתרים רשימה של gmp_app_id ורשימה של client_namespace.
    
    ב-BigQuery, מזהה האפליקציה ב-Firebase נקרא gmp_app_id. כברירת מחדל, הערך של client_namespace ב-BigQuery הוא מזהה החבילה הייחודי או שם החבילה התואם של האפליקציה, אבל אתם תבטלו את הגדרת ברירת המחדל הזו.
    
    ‫BigQuery משתמש בערך client_namespace כשם של טבלת האצווה שכל אפליקציה מקושרת של Firebase כותבת אליה.
  5. מחפשים את gmp_app_id של האפליקציה ב-Firebase שרוצים לשנות את הגדרות ברירת המחדל שלה. משנים את הערך של client_namespace לשם של הטבלה שאליה רוצים שהאפליקציה ב-Firebase תכתוב (בדרך כלל זה השם של הטבלה מדור קודם שאליה האפליקציה כתבה באמצעות תשתית הייצוא מדור קודם).
    
    הערה: אם כתבתם בעבר לטבלה אחת ועכשיו יש לכם כמה טבלאות אחרי השדרוג, אתם יכולים להשתמש באותו client_namespace לכל gmp_app_id רלוונטי. BigQuery בעצם ימוזגו כל הטבלאות וכל הנתונים של כל האפליקציות ב-Firebase ייכתבו בטבלה אחת.
  6. שומרים את השינוי בהגדרה.
3. מגדירים מילוי חוסרים לימים שבהם חסרים נתונים בטבלה מדור קודם.
4. אחרי שהמילוי החוזר מסתיים, מוחקים את הטבלה החדשה שנוצרה אוטומטית על ידי תשתית הייצוא החדשה.

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

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

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

יומני פעולות משתמש לא מוצגים

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

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

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

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

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

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

תמיכה ספציפית לפלטפורמה

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

חסרים קובצי dSYM או שהם לא מועלים

הקריסות לא מסומלות בצורה טובה

אפשר להשתמש ב-Crashlytics ב-macOS או ב-tvOS?

האם אפשר להשתמש ב-Crashlytics בפרויקט Firebase עם כמה אפליקציות בפלטפורמות שונות של Apple?

תמיכה ב-Android

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

למה בחלק מה-ANR לא מופיע BuildId?

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

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

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

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

איך משדרגים לגרסה 3 של הפלאגין Crashlytics Gradle

דרישות מינימליות

Kotlin

Groovy

שינויים בתוסף Crashlytics

דוגמה לשדרוג התוסף

Kotlin

Groovy

תמיכה ספציפית ל-Android-NDK

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

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

גרסה 3.0.0 ואילך של Gradle Plugin

גרסאות ישנות יותר של התוסף

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

תמיכה ב-Unity

הצגת עקבות מחסנית (stack traces) לא מסומלים של אפליקציות ל-Android בלוח הבקרה Crashlytics

האם אפשר להשתמש ב-Crashlytics עם אפליקציות שמשתמשות ב-IL2CPP?

דיווח על חריגים שלא זוהו כשגיאות חמורות

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

אילו חריגים ידווחו כשגיאות חמורות?

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

איך לזהות חריגים שנוצרו ולטפל בהם

רישום חריגים ב-Unity או ב-Crashlytics

תמיכה בשילובים

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

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

נתקלתם בבעיות אחרי ששדרגתם לתשתית הייצוא החדשה של BigQuery?

ההבדלים החשובים בין תשתית הייצוא הישנה לבין תשתית הייצוא החדשה

אם השם של טבלת האצווה הקודמת לא תאם למזהה האפליקציה ב-Firebase

הסבר על האופן שבו מזהים משמשים את תשתית הייצוא לכתיבת נתונים בטבלאות BigQuery

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

תרחישים לדוגמה של מזהים לא תואמים

אפשרויות לצמצום ההפרעה

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

למה בחלק מה-ANR לא מופיע `BuildId`?

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

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