‫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 (הרשאות)

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

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

תכונה	ההרשאה שנדרשת כדי לקבל התראה	תפקידים שכוללים את ההרשאה הנדרשת כברירת מחדל
Crashlytics – התראות באפליקציה לנייד	`firebase.projects.update`	בעלים עריכה אדמין ב-Firebase
Crashlytics – התראות מאפליקציית האינטרנט	`monitoring.alertPolicies.create` `monitoring.alertPolicies.update` `monitoring.notificationChannels.create`	בעלים עריכה עריכת מעקב

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

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

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

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

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

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

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

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

כשחבר בפרויקט מפרסם הערה, היא מסומנת בתווית עם כתובת האימייל של חשבון 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, שמאפשר ל-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 לבין דוחות ה-ANR ב-Google Play Console

יכול להיות חוסר התאמה בין מספר מקרי ה-ANR ב-Google Play לבין המספר ב-Crashlytics. זה צפוי בגלל ההבדל במנגנון של איסוף נתוני ה-ANR והדיווח עליהם. Crashlytics מדווח על מקרי ANR כשהאפליקציה מופעלת בפעם הבאה, ואילו תפקוד האפליקציה שולח נתוני 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 בגרסה העדכנית של Android Studio.
‫google-services פלאגין Gradle בגרסה 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 יש ברירות מחדל וטיפולים שונים בקטע לקריאה בלבד של הקבצים הבינאריים של האפליקציה, מה שעלול ליצור דוחות קריסה לא עקביים במסוף 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.

תמיכה באינטרנט

מוצגת השגיאה `Component crashlytics has not been registered yet`

כשמשתמשים בחבילה @firebase/crashlytics, אל תערבבו מרחבי שמות מודולריים בייבוא. ייבוא של initializeApp מ-firebase/app בזמן שמייבאים את getCrashlytics מ-@firebase/crashlytics גורם לכלים לאיסוף חבילות לטעון שני מרשמים פנימיים נפרדים, וכתוצאה מכך מתקבלות שגיאות כמו Component crashlytics has not been registered yet.

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

צריך להגדיר את כל הייבוא של Firebase בפרויקט כך שישתמש במרחב השמות @firebase/ (לדוגמה, @firebase/app ו-@firebase/crashlytics).

אם האפליקציה משתמשת ב-Vite, צריך להסיר כפילויות של @firebase/app באופן מפורש בקובץ vite.config.ts:

// vite.config.ts
import { defineConfig } from 'vite';

export default defineConfig({
  resolve: {
    dedupe: ['@firebase/app']
  }
});

שגיאת קומפילציה של TypeScript כשהאפשרות `verbatimModuleSyntax` מופעלת

בהגדרות מודרניות של TypeScript (כמו תבניות Vite ו-Angular) לעיתים קרובות מופעלת האפשרות "verbatimModuleSyntax": true ב-tsconfig.json. כשהדגל הזה מופעל, ייבוא של ממשק TypeScript באמצעות ייבוא ערך רגיל גורם לשגיאת קומפילציה.

כשמייבאים ממשקי TypeScript כמו FirebaseApp או Crashlytics, צריך להשתמש בייבוא מפורש של type:

import { initializeApp, type FirebaseApp } from '@firebase/app';
import { getCrashlytics, type Crashlytics } from '@firebase/crashlytics';

תמיכה ב-Unity

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

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

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

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

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

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

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

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

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

להבין איך תשתית הייצוא משתמשת במזהים כדי לכתוב נתונים בטבלאות של 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 קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

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

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

לא מתקבלות התראות מ-Crashlytics (הרשאות)

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

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

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

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

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

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

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

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

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

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

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

תמיכה ב-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?

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

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

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

תמיכה באינטרנט

מוצגת השגיאה Component crashlytics has not been registered yet

שגיאת קומפילציה של TypeScript כשהאפשרות verbatimModuleSyntax מופעלת

תמיכה ב-Unity

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מוצגת השגיאה `Component crashlytics has not been registered yet`

שגיאת קומפילציה של TypeScript כשהאפשרות `verbatimModuleSyntax` מופעלת