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

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

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

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

• תמיכה שספציפית לפלטפורמה, כולל שאלות שספציפיות לפלטפורמות של אפל, ל-Android ול-Unity.

• תמיכה בשילובים, כולל שאלות לגבי BigQuery.

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

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

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

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

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

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

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

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

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

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

• ניפוי באגים קל יותר בבעיות מורכבות עם מגוון סיבות שורש
  אפשר להשתמש בווריאציות כדי לנפות באגים במעקב אחר מחסנית (stack trace) הנפוץ ביותר בבעיה.

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

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

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

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

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

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

לא רואים יומנים של נתיבי מיקום

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

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

• הפעלתם את שיתוף הנתונים עבור Google 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 יש מידע על קריסות רק מהמשתמשים שהביעו הסכמה (ולא מכל המשתמשים). כלומר, יכול להיות שהמדדים של אפליקציות ללא קריסות יהיו פחות מהימנים ופחות ישקפו את היציבות הכוללת של האפליקציה.

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

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

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

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

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

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

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

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

  • בעלים או עורך של הפרויקט, אדמין ב-Firebase, אדמין של איכות, או אדמין של Crashlytics

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

  • בעל הרשאת צפייה בפרויקט, בעל הרשאת צפייה ב-Firebase, בעל הרשאת צפייה באיכות או בעל הרשאת צפייה ב-Crashlytics

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

1. מוודאים ששלב הבנייה של הפרויקט מכיל את Crashlytics run script, שמאפשר ל-Xcode להעלות את קובצי ה-dSYM של הפרויקט בזמן הבנייה (הוראות להוספת הסקריפט מופיעות במאמר Initializing Crashlytics). אחרי עדכון הפרויקט, מכריחים את האפליקציה לקרוס ומוודאים שהקריסה מופיעה בלוח הבקרה של Crashlytics.

2. אם מופיעה התראה 'חסר dSYM' במסוף Firebase, בודקים ב-Xcode כדי לוודא שנוצרים קובצי dSYM בצורה תקינה עבור ה-build.

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

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

   • מעלים ידנית את קובצי ה-dSYM החסרים:

     • אפשרות 1: משתמשים באפשרות 'גרירה ושחרור' שמבוססת על מסוף בכרטיסייה dSYMs כדי להעלות ארכיון zip שמכיל את קובצי ה-dSYM החסרים.
     • אפשרות 2: משתמשים בסקריפט upload-symbols כדי להעלות את קובצי ה-dSYM החסרים, עבור ה-UUID שמופיעים בכרטיסייה dSYMs.

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

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

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

• אם חסרים פריימים בספריית האפליקציה שלכם שמתייחסים לקוד האפליקציה, ודאו ש--fomit-frame-pointer לא מוגדר כדגל קומפילציה.

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

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

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

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

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

• חשוב לוודא שאתם משתמשים בגרסה עדכנית של 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 לא יוכל לאתר את BuildIds המשויכים. מומלץ להשתמש במיקום הרגיל לספריות משותפות.

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

  הערה: הטיפים הבאים לפתרון בעיות רלוונטיים גם ל-ANR וגם לקריסות של אפליקציות מובנות.

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

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

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

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

יכול להיות שיהיה הבדל בין מספר שגיאות ה-ANR שמוצג ב-Google Play לבין מספר שגיאות ה-ANR שמוצג ב-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

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

1. מוודאים שמשתמשים בגרסה האחרונה של DexGuard 8.x. הגרסה האחרונה כוללת כללים שנדרשים על ידי SDK‏ Firebase Crashlytics.

2. אם אתם לא רוצים לשנות את הגרסה של DexGuard, נסו להוסיף את השורה הבאה לכללי ההסתרה (בקובץ ההגדרות של DexGuard):

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

איך משדרגים ל-Crashlytics Gradle plugin v3?

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

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

לתוסף Crashlytics Gradle v3 יש את דרישות המינימום הבאות:

• ‫Android Gradle plugin 8.1+
  כדי לשדרג את הפלאגין הזה, צריך להשתמש בAndroid Gradle plugin Upgrade Assistant בגרסה העדכנית ביותר של Android Studio.

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

Kotlin

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

Groovy

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.4.4' 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. כדי לפתור את הבעיה, מוסיפים את דגלי ה-linker הבאים לתהליך הבנייה:

• אם אתם משתמשים ב-linker‏ lld מ-LLVM toolchain, מוסיפים:

  -Wl,--no-rosegment

• אם אתם משתמשים במקשר ld.gold מ-GNU toolchain, מוסיפים:

  -Wl,--rosegment

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

-fno-omit-frame-pointer

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

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

הערה: נדרשת גרסת Linux של כלי ליצירת קובצי סמלים של Breakpad עבור קבצים בינאריים של Android.

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

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

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

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

  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.properties

  אפשר להשתמש במאפיין 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

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

1. מוודאים שמשתמשים בגרסה v8.6.1 ואילך של Crashlytics Unity SDK.

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

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

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

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

1. מוודאים שמשתמשים בגרסה 8.6.0 ואילך של Crashlytics Unity SDK.

2. משלימים את המשימות הנדרשות בפלטפורמה:

   • באפליקציות לפלטפורמת Apple: לא נדרשות פעולות מיוחדות. באפליקציות לפלטפורמת Apple, התוסף Firebase Unity Editor מגדיר באופן אוטומטי את פרויקט Xcode להעלאת סמלים.

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

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

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

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

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

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

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

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

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

כדי ש-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.

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

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

איך משדרגים לתשתית הייצוא החדשה של BigQuery?

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

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

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

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

אפשר לשדרג לתשתית החדשה, אבל חשוב לוודא שטבלאות ה-batch שלכם ב-BigQuery עומדות בדרישות המוקדמות לשדרוג.

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

איך יודעים אם אתם משתמשים בתשתית החדשה

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

כדי לבדוק באיזו תשתית הפרויקט שלכם משתמש: נכנסים למסוף Google Cloud, ואם ההגדרה של העברת הנתונים מסומנת בתווית Firebase Crashlytics with Multi-Region Support, סימן שהפרויקט שלכם משתמש בתשתית הייצוא החדשה.

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

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

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

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

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

  • במערכת הישנה, מילוי החוסרים (backfill) היה אפשרי עד 30 ימים לפני התאריך שבו הפעלתם את הייצוא.

  • התשתית החדשה תומכת במילוי חוסרים עד 30 הימים האחרונים או עד התאריך האחרון שבו הפעלתם את הייצוא אל BigQuery (התאריך המאוחר מביניהם).

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

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

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

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

שלב 1: תנאי מוקדם לשדרוג

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

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

   • אפשר למצוא את כל הטבלאות של אצווה בBigQuery בדף Google Cloud במסוף.BigQuery

   הערה: טבלאות של נתונים בזמן אמת שמסתיימות ב-REALTIME לא מושפעות מהתשתית החדשה לייצוא, ואפשר להתעלם מהן.
   BigQuery

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

   • יש לכם טבלת נתונים בכמות גדולה בשם com_yourcompany_yourproject_IOS ואפליקציית Firebase ל-iOS+ עם מזהה החבילה com.yourcompany.yourproject שרשומות בפרויקט Firebase.

   • יש לכם טבלת נתונים בכמות גדולה בשם com_yourcompany_yourproject_ANDROID ואפליקציית Firebase ל-Android עם שם החבילה com.yourcompany.yourproject שרשומה בפרויקט Firebase.

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

שלב 2: שדרוג ידני לתשתית החדשה

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

אלה השלבים המפורטים:

1. במסוף Firebase, עוברים לדף Integrations.

2. בכרטיס BigQuery, לוחצים על ניהול.

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

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

   ייצוא הנתונים של Crashlytics אל BigQuery מתבצע עכשיו באמצעות תשתית הייצוא החדשה.

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

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

אם יש לכם טבלאות קיימות של BigQuery batch בסטטוס הזה, זה אומר שהן לא תואמות לתשתית החדשה של Firebase לייצוא BigQuery batch. שימו לב: כל הפרויקטים ב-Firebase יועברו באופן אוטומטי לתשתית החדשה של הייצוא החל מ-9 בינואר 2026.

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

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

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

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

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

חשוב: אם יש לכם שאלות או שאתם לא מרגישים בנוח ליישם אחת מהאפשרויות האלה, אתם יכולים לפנות אל התמיכה של Firebase.

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

  1. במסוף Firebase, צריך לשדרג לתשתית הייצוא החדשה על ידי השבתת הייצוא והפעלה שלו מחדש עבור האפליקציה המקושרת.

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

  2. במסוף Google Cloud, מעתיקים את כל הנתונים מהטבלה הקודמת לטבלה החדשה שנוצרה.

  3. אם יש לכם יחסי תלות במורד הזרם שתלויים בטבלת האצווה, צריך לשנות אותם כך שישתמשו בטבלה החדשה.

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

• אפשרות 2:
  להמשיך לכתוב בטבלה הקיימת. כדי לעשות את זה, תצטרכו לבטל חלק מההגדרות שמוגדרות כברירת מחדל בקובץ BigQuery config.

  1. במסוף Firebase, מאתרים את מזהה האפליקציה ב-Firebase (למשל, 1:1234567890:ios:321abc456def7890) של האפליקציה עם שם הטבלה ומזהה האצווה שלא תואמים ורושמים אותו:
     עוברים אל Project settings (הגדרות הפרויקט), ואז אל הכרטיס Your apps (האפליקציות שלך) כדי לראות את כל האפליקציות ב-Firebase והמידע שלהן.

  2. במסוף Firebase, צריך לשדרג לתשתית הייצוא החדשה על ידי השבתת הייצוא והפעלה שלו מחדש עבור האפליקציה המקושרת.

     הפעולה הזו עושה שני דברים:

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

     • יוצר BigQuery 'הגדרת העברת נתונים' עם המקור Firebase Crashlytics with Multi-Region Support.

  3. במסוף 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. שומרים את השינוי בהגדרות.

  4. מתזמנים מילוי חוסרים לימים שבהם חסרים נתונים בטבלה הקיימת.

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