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

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

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

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

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

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

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

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

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

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

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

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

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

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

כך השיפורים האלה יושקו:

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

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

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

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

הפעלתם את Google Analytics בפרויקט שלכם ב-Firebase.
הפעלת את שיתוף הנתונים ב-Google Analytics. מידע נוסף על ההגדרה הזו זמין במאמר ניהול של הגדרות שיתוף הנתונים מ-Analytics.
הוספתם לאפליקציה את Firebase SDK ל-Google Analytics: iOS+‎ | Android | Flutter | Unity.
צריך להוסיף את ה-SDK הזה בנוסף ל-SDK של Crashlytics.
אתם משתמשים בגרסאות העדכניות ביותר של 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 SDK:
חשוב לוודא שהגדרות איסוף הנתונים לא משפיעות על איכות המדדים של הפעלות ללא קריסה:
- אם מפעילים את הדיווח בהבעת הסכמה על ידי השבתת הדיווח האוטומטי על קריסות, אפשר לשלוח מידע על קריסות אל Crashlytics רק ממשתמשים שהביעו הסכמה מפורשת לאיסוף נתונים. לכן, הדיוק של המדדים ללא קריסות יושפע, כי ל-Crashlytics יש מידע על קריסות רק מהמשתמשים שהביעו הסכמה (ולא מכל המשתמשים). זה אומר שהמדדים של הפעלות ללא קריסה עשויים להיות פחות מהימנים ופחות מייצגים את היציבות הכוללת של האפליקציה.
- אם איסוף הנתונים האוטומטי מושבת, אפשר להשתמש ב-sendUnsentReports כדי לשלוח דוחות ששמורים במטמון במכשיר אל Crashlytics. אם משתמשים בשיטה הזו, נתוני הקריסות נשלחים אל Crashlytics, אבל נתוני הסשנים לא נשלחים. לכן, בתרשימים של מסוף Play מוצגים ערכים נמוכים או אפסיים במדדים של סשנים ללא קריסות.

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

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

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

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

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

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

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

מהי בעיה שחזרה?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

עכשיו אתם יכולים לדווח על קריסות בכמה אפליקציות בפרויקט Firebase אחד, גם אם האפליקציות מיועדות לפלטפורמות שונות של אפל (לדוגמה, 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, פתרו את הבעיה באופן הבא:

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

אם חסרים לכם קובצי 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+‎
בודקים אם אתם משתמשים במיקום לא סטנדרטי לספריות המשותפות.

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

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

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

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

בנוסף, ב-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 היא גרסה ראשית (v3.0.0) והיא משדרגת את ה-SDK על ידי הפסקת התמיכה בגרסאות ישנות יותר של Gradle ושל הפלאגין של Android Gradle. בנוסף, השינויים בגרסה הזו פותרים בעיות ב-AGP בגרסה 8.1 ואילך, ומשפרים את התמיכה באפליקציות נייטיב ובגרסאות build בהתאמה אישית.

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

אלה דרישות הסף של פלאגין Gradle בגרסה 3 של Crashlytics:

‫פלאגין של Android Gradle 8.1 ואילך
כדי לשדרג את הפלאגין הזה, משתמשים ב-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, בתוסף 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.

החלפנו את השדה closure 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 יש ברירות מחדל וטיפולים שונים בקטע לקריאה בלבד של קובצי ה-binary של האפליקציה, מה שעלול ליצור דוחות קריסה לא עקביים במסוף Firebase. כדי לפתור את הבעיה, מוסיפים את דגלי הקישור הבאים לתהליך ה-build:

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

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

-fno-omit-frame-pointer

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

הפלאגין 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
```

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

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

תמיכה ב-Unity

הצגת דוחות קריסות ללא סמלים של אפליקציות ל-Android בלוח הבקרה של Crashlytics

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

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

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

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

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

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

דיווח על חריגות שלא נתפסו כחריגות קריטיות

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

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

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

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

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

כדי ש-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 לצד ה-SDK של Google Mobile Ads, סביר להניח שדיווח הקריסות מפריע לרישום של מטפלים בחריגות. כדי לפתור את הבעיה, צריך להשבית את הדיווח על קריסות ב-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 (המאוחר מביניהם).
התשתית החדשה נותנת שמות לטבלאות של ה-Batch ב-BigQuery לפי המזהים שהוגדרו לאפליקציות Firebase בפרויקט Firebase.
- התשתית הישנה כתבה נתונים לטבלאות אצווה עם שמות שמבוססים על מזהי החבילות או שמות החבילות בקובץ הבינארי של האפליקציה.
- התשתית החדשה כותבת נתונים לטבלאות אצווה עם שמות שמבוססים על מזהי החבילות או שמות החבילות שהוגדרו לאפליקציות Firebase הרשומות בפרויקט Firebase.

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

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

להבין איך תשתית הייצוא משתמשת במזהים כדי לכתוב נתונים בטבלאות של BigQuery

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

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

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

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

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

הנתונים של Crashlytics נכתבים עכשיו בטבלת אצווה חדשה של 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 ‏> Data transfers.
  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 עם כמה אפליקציות בפלטפורמות שונות של אפל?

תמיכה ב-Android

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

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

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

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

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

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

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

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

Kotlin

Groovy

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

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

Kotlin

Groovy

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

ההבדלים בין דוחות קריסות של NDK במרכז הבקרה של Crashlytics לבין logcat

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

פלאגין Gradle בגרסה 3.0.0 ואילך

גרסאות פלאגין ישנות יותר

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

תמיכה ב-Unity

הצגת דוחות קריסות ללא סמלים של אפליקציות ל-Android בלוח הבקרה של Crashlytics

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

דיווח על חריגות שלא נתפסו כחריגות קריטיות

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

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

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

תפיסה וטיפול בחריגים שנזרקו

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

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

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

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

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

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

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

להבין איך תשתית הייצוא משתמשת במזהים כדי לכתוב נתונים בטבלאות של BigQuery

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

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

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

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

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

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

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