קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
בדף הזה תוכלו למצוא עזרה בפתרון בעיות ותשובות לשאלות נפוצות
שאלות על השימוש ב-Crashlytics. אם לא מצאתם את מה שחיפשת או אם אתם זקוקים לעזרה נוספת, תוכלו לפנות אל התמיכה של Firebase.
פתרון בעיות כלליות/שאלות נפוצות
פורמטים שונים (ולפעמים 'וריאנטים') של בעיות מסוימות בטבלה בעיות
ייתכן שבטבלה בעיות יוצגו שני פורמטים שונים לבעיות
במסוף Firebase. יכול להיות שתבחינו גם בתכונה שנקראת 'וריאנטים' בחלק מהבעיות. זו הסיבה!
בתחילת 2023 השקנו מנוע ניתוח משופר לקיבוץ אירועים בתור
וגם עיצוב מעודכן וכמה תכונות מתקדמות לבעיות חדשות (כמו
וריאציות!). כדאי לעיין בעדכונים האחרונים שלנו
פוסט בבלוג
את כל הפרטים, אבל אפשר לקרוא בהמשך על הפרטים העיקריים.
Crashlytics מנתח את כל האירועים מהאפליקציה (כמו קריסות, אירועים לא קטלניים ומקרי ANR) ויוצר קבוצות של אירועים שנקראות בעיות – לכל האירועים בבעיה יש נקודת כשל משותפת.
כדי לקבץ אירועים לפי הבעיות האלה, מנוע הניתוח המשופר בוחן עכשיו
הרבה היבטים של האירוע, כולל הפריימים בדוח הקריסות,
הודעת חריגה, קוד השגיאה ופלטפורמה או סוג שגיאה אחרים
למאפיינים.
עם זאת, בתוך קבוצת האירועים הזו, דוחות הקריסות שהובילו לכשל
עשוי להיות שונה. אם דוח אחר של נתוני סטאק יהיה שונה, יכול להיות שמדובר בגורם אחר לבעיה.
כדי לייצג את ההבדל האפשרי הזה בתוך בעיה, אנחנו יוצרים עכשיו וריאציות בתוך בעיות – כל וריאנט הוא קבוצת משנה של אירועים בבעיה שיש להם את אותו נקודת כשל וגם נתיב סטאק דומה. בעזרת וריאנטים תוכלו לנפות באגים בנתוני המעקב הנפוצים ביותר בבעיה, ולבדוק אם יש סיבות שונות לבעיה.
תוכלו ליהנות מהשיפורים האלה:
מטא-נתונים משופרים מוצגים בשורת הבעיה עכשיו קל יותר להבין בעיות באפליקציה ולטפל בהן.
פחות בעיות כפולות שינוי של מספר שורה לא יוצר בעיה חדשה.
ניפוי באגים קל יותר של בעיות מורכבות עם גורמי שורש שונים אפשר להשתמש בוריאנטים כדי לנפות באגים בנתוני המעקב הנפוצים ביותר בבעיה.
התראות ואותות משמעותיים יותר בעיה חדשה מייצגת באג חדש.
חיפוש יעיל יותר כל בעיה מכילה יותר מטא-נתונים שאפשר לחפש, כמו סוג החריגה ושם החבילה.
כך אנחנו משיקים את השיפורים האלה:
כשנקבל אירועים חדשים מהאפליקציה שלכם, נבדוק אם הם תואמים לבעיה קיימת.
אם לא נמצאה התאמה, נחיל באופן אוטומטי את קיבוץ האירועים החכם יותר
האלגוריתם של האירוע וליצור בעיה חדשה עם המטא-נתונים המשופרים
לעיצוב.
זהו העדכון המשמעותי הראשון שאנחנו מבצעים לקיבוץ האירועים. אם יש לכם משוב או אם נתקלת בבעיות, אפשר לשלוח דיווח.
לא מוצגים מדדים של נסיעות ללא תאונות או התראות על מהירות
אם המדדים של 'ללא קריסות' (כמו משתמשים וסשנים ללא קריסות) ו/או ההתראות לגבי מהירות לא מוצגים, צריך לוודא שאתם משתמשים ב-
Crashlytics SDK v18.6.0 ואילך (או Firebase BoM v32.6.0 ואילך).
היומנים של נתיבי הניווט לא מוצגים
אם יומני הלחם לא מופיעים, מומלץ לבדוק את ההגדרות של האפליקציה לגבי Google Analytics.
צריך לעמוד בדרישות הבאות:
חשוב במיוחד לוודא שאתם משתמשים לפחות בגרסה הבאה של
Firebase SDK עבור Google Analytics: Android — גרסה 17.2.3 ואילך(BoM מגרסה 24.7.1 ואילך).
למה דיווח על מקרי ANR מתבצע רק לגבי Android מגרסה 11 ואילך?
Crashlytics תומך בדיווח על ANR לאפליקציות ל-Android ממכשירים עם Android מגרסה 11 ואילך. ממשק ה-API הבסיסי שבו אנחנו משתמשים כדי לאסוף דיווחים על ANR (getHistoricalProcessExitReasons) מהימן יותר מגישות שמבוססות על SIGQUIT או על watchdog. ממשק ה-API הזה זמין רק במכשירי Android מגרסה 11 ואילך.
למה חלק ממקרי ה-ANR חסרים
BuildId?
אם בחלק מהאירועים של ANR חסרים BuildId, פותרים את הבעיה באופן הבא:
חשוב לוודא שנעשה שימוש בערכת Android SDK עדכנית של Crashlytics וגם
Crashlytics גרסת הפלאגין של Gradle.
אם חסרים לכם BuildIds ל-Android 11 ולחלק מה-ANRs של Android 12, סביר להניח שאתם משתמשים ב-SDK, בפלאגין של Gradle או בשניהם בגרסה מיושנת.
כדי לאסוף באופן תקין מקרי BuildId למקרי ה-ANR האלה, צריך להשתמש במשאבים הבאים
גרסאות:
כדאי לבדוק אם נעשה שימוש במיקום לא סטנדרטי לספריות המשותפות.
אם חסרים לך BuildId רק בספריות המשותפות של האפליקציה, סביר להניח
שאתם לא משתמשים בו במיקום הרגיל שמוגדר כברירת מחדל לספריות משותפות. במקרה כזה, יכול להיות ש-Crashlytics לא יוכל לאתר את הערכים המשויכים של BuildId. מומלץ לשקול להשתמש במודל
את המיקום לספריות משותפות.
חשוב לוודא שלא מסירים את ה-BuildId במהלך תהליך ה-build.
חשוב לדעת שהטיפים הבאים לפתרון בעיות רלוונטיים גם ל-ANR וגם לקריסות של קוד מקורי.
כדי לבדוק אם קובצי ה-BuildId קיימים, מריצים את readelf -n בקובצי ה-binary. אם הערכים של BuildId לא מופיעים, צריך להוסיף את הערך -Wl,--build-id לדגלים של מערכת ה-build.
בודקים שלא הסרתם בטעות את ה-BuildId בלי כוונה
כדי להקטין את גודל ה-APK.
אם שומרים גרסאות ספרייה שהושמטו וגרסאות ספרייה שלא הושמטו, חשוב להפנות לגרסת הספרייה הנכונה בקוד.
הבדלים
בין דוחות ANR במרכז הבקרה Crashlytics לבין
Google Play Console
יכול להיות חוסר התאמה בין מספר ה-ANR ב-Google Play לבין מספר ה-ANR ב-Crashlytics. הדבר צפוי עקב ההבדל במנגנון של
איסוף נתונים על מקרי ANR ודיווח עליהם. Crashlytics מדווח על מקרי ANR כשהאפליקציה
הבא, ואילו התכונה 'תפקוד האפליקציה' שולחת נתוני ANR אחרי שמתרחשת ה-ANR.
בנוסף, Crashlytics מציג מקרי ANR שמתרחשים רק במכשירים פועלים
Android מגרסה 11 ואילך, בהשוואה ל-Google Play שבה מוצגים מקרי ANR ממכשירים עם
ההסכמה לאיסוף נתונים ולשירותי Google Play Services אושרה.
הבדלים
בין דוחות הקריסות של NDK בלוח הבקרה של Crashlytics לבין Logcat
ל-LLVM ול-GNU יש ברירת מחדל וטיפולים שונים לקטע לקריאה בלבד של קובצי ה-binary של האפליקציה, שעשויים ליצור קווים לא עקביים של סטאק במסוף Firebase. כדי לצמצם את הסיכון, כדאי להוסיף את דגלי הקישור הבאים
לתהליך ה-build:
אם משתמשים ב-lld המקשר מתוך LLVM Toolchain צריך להוסיף:
-Wl,--no-rosegment
אם משתמשים ב-ld.gold Linker מתוך GNU Toolchain, צריך להוסיף:
-Wl,--rosegment
אם עדיין יש חוסר עקביות בדוח הקריסות (או אם אף אחד מהדגלים לא מוגדר
שרלוונטיים ל-toolchain, לנסות להוסיף את הדברים הבאים לתהליך ה-build
במקום זאת:
-fno-omit-frame-pointer
איך משתמשים ב-NDK במחולל הבינארי של קובצי הסמלים של Breakpad?
הפלאגין Crashlytics כולל מחולל מותאם אישית של קובץ סמלים של Breakpad.
אם אתם מעדיפים להשתמש בקובץ הבינארי שלכם ליצירת קובצי הסמל של Breakpad (לדוגמה, אם אתם מעדיפים ליצור את כל קובצי ההפעלה הנתמכים בשרשרת ה-build שלכם מהמקור), תוכלו להשתמש במאפיין האפשרי של התוסף symbolGeneratorBinary כדי לציין את הנתיב לקובץ ההפעלה.
אפשר לציין את הנתיב לקובץ הבינארי של ה-generator של קובצי הסמלים של Breakpad באחת משתי דרכים:
אפשרות 1: ציון הנתיב דרך firebaseCrashlytics
הסיומת בקובץ build.gradle
מוסיפים את הפרטים הבאים לקובץ build.gradle.kts ברמת האפליקציה:
פלאגין Gradle מגרסה 3.0.0 ואילך
android {
buildTypes {
release {
configure<CrashlyticsExtension> {
nativeSymbolUploadEnabled = true
// Add these optional fields to specify the path to the executable
symbolGeneratorType = "breakpad"
breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
}
}
}
}
גרסאות פלאגין נמוכות יותר
android {
// ...
buildTypes {
// ...
release {
// ...
firebaseCrashlytics {
// existing; required for either symbol file generator
nativeSymbolUploadEnabled true
// Add this optional new block to specify the path to the executable
symbolGenerator {
breakpad {
binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
}
}
}
}
}
אפשרות 2: ציון הנתיב דרך קו מאפיין ב-Gradle
קובץ מאפיינים
אפשר להשתמש ב-com.google.firebase.crashlytics.breakpadBinary
כדי לציין את הנתיב לקובץ ההפעלה.
אפשר לעדכן באופן ידני את קובץ המאפיינים של Gradle או לעדכן את הקובץ
באמצעות שורת הפקודה. לדוגמה, כדי לציין את הנתיב באמצעות הפקודה
השתמש בפקודה כמו:
למה אני רואה קריסות
מ-.kt קבצים שתויגו כבעיות מסוג .java?
כשאפליקציה משתמשת בתוכנה להסתרת קוד שלא חושפת את סיומת הקובץ, Crashlytics יוצרת כל בעיה עם סיומת הקובץ .java כברירת מחדל.
כדי שמערכת Crashlytics תוכל ליצור בעיות עם סיומת הקובץ הנכונה,
צריך לוודא שהאפליקציה משתמשת בהגדרות הבאות:
שימוש ב-Android Gradle 4.2.0 ואילך
נעשה שימוש ב-R8 כשמופעל ערפול קוד (obfuscation). כדי לעדכן את האפליקציה ל-R8, פועלים לפי המסמכים האלה.
שימו לב: אחרי העדכון להגדרה שמתוארת למעלה, יכול להיות שתתחילו לראות בעיות חדשות בנושא .kt שהן כפילויות של בעיות קיימות בנושא .java. לצפייה
שאלות נפוצות לקבלת מידע נוסף על הנסיבות.
למה אני רואה
.kt בעיות שהן כפילויות של בעיות קיימות
.java בעיות?
החל מאמצע דצמבר 2021, Crashlytics שיפרה את התמיכה באפליקציות שמשתמשות ב-Kotlin.
עד לאחרונה, התוכנות להסתרת קוד לא חשפו את סיומת הקובץ, ולכן Crashlytics יצר כל בעיה עם סיומת הקובץ .java כברירת מחדל.
עם זאת, החל מ-Android Gradle 4.2.0, ב-R8 יש תמיכה בסיומות קבצים.
בעזרת העדכון הזה, Crashlytics יכול עכשיו לקבוע אם כל הכיתה שבה נעשה שימוש באפליקציה נכתבה ב-Kotlin, ולכלול את שם הקובץ הנכון בחתימת הבעיה. אם האפליקציה שלכם מוגדרת באופן הבא, מעכשיו קריסות יופיעו בקבצים .kt (לפי הצורך):
באפליקציה שלך נעשה שימוש ב-R8 עם ערפול קוד (obfuscation).
מאחר שתאונות חדשות כוללות עכשיו את סיומת הקובץ הנכונה בחתימות שלהן, יכול להיות שתראו בעיות חדשות עם התווית .kt שהן למעשה רק כפילויות של בעיות קיימות עם התווית .java. במסוף Firebase אנחנו מנסים לזהות
ותיידע אותך אם בעיה חדשה בנושא .kt היא כפילות של
בעיה קיימת שמסומנת בתווית .java.
מי יכול לראות, לכתוב ולמחוק הערות בבעיה?
הערות מאפשרות למשתתפי הפרויקט להגיב על בעיות ספציפיות, לשאול שאלות, לעדכן את הסטטוס וכו'.
כשחבר בפרויקט מפרסם הערה, היא מסומנת בתווית האימייל של חשבון Google
חשבון. כתובת האימייל הזו, יחד עם ההערה, גלויות לכל חברי הפרויקט שיש להם גישה להערה.
בהמשך מתוארת רמת הגישה הנדרשת לצפייה, לכתיבה ולמחיקה
הערות:
חברי צוות בפרויקט עם אחד מהתפקידים הבאים יכולים להציג ולמחוק הערות קיימות ולכתוב הערות חדשות בבעיה.
הערות מאפשרות למשתתפי הפרויקט להגיב על בעיות ספציפיות, לשאול שאלות, לעדכן את הסטטוס וכו'.
כשחבר בפרויקט מפרסם הערה, היא מסומנת בתווית האימייל של חשבון Google
חשבון. כתובת האימייל הזו, יחד עם ההערה, גלויות לכל חברי הפרויקט שיש להם גישה להערה.
בהמשך מתוארת רמת הגישה הנדרשת לצפייה, לכתיבה ולמחיקה
הערות:
חברי צוות בפרויקט עם אחד מהתפקידים הבאים יכולים להציג ולמחוק הערות קיימות ולכתוב הערות חדשות בבעיה.
באפליקציה נעשה שימוש גם ב-SDK של Google Mobile Ads, אבל לא מתרחשות קריסות
אם בפרויקט נעשה שימוש ב-Crashlytics לצד ה-SDK של Google Mobile Ads,
סביר להניח שדיווחי הקריסה מפריעים
רישום handlers חריגים. כדי לפתור את הבעיה, צריך להשבית את דיווח הקריסה בקטע
ל-SDK Mobile Ads יש לשלוח קריאה אל disableSDKCrashReporting.
איפה נמצא מערך הנתונים שלי ב-BigQuery?
אחרי שמקשרים את Crashlytics ל-BigQuery, מערכי הנתונים החדשים שיצרתם ממוקמים באופן אוטומטי בארצות הברית, ללא קשר למיקום של פרויקט Firebase.
תמיכה בפלטפורמות
האם Crashlytics תומך ב-armeabi?
השדה Firebase Crashlytics NDK לא תומך ב-ARMv5 (armeabi).
התמיכה ב-ABI הזה הוסרה החל מ-NDK r17.
בעיות שחוזרות על עצמן
מהי רגרסיה (רגרסיה)
בעיה?
הבעיה חוזרת אם סגרתם אותה בעבר אבל קיבלתם דיווח חדש על כך שהיא חוזרת Crashlytics.
Crashlytics פותח מחדש באופן אוטומטי את הבעיות האלה כדי שתוכלו לטפל בהן בהתאם לאפליקציה שלכם.
הנה תרחיש לדוגמה שמסביר איך Crashlytics מסווג
בתור רגרסיה:
בפעם הראשונה אי פעם, Crashlytics מקבל דוח קריסה לגבי קריסה
"A". Crashlytics פותח בעיה תואמת לקריסה הזו (בעיה 'א').
מתקנים את הבאג במהירות, סוגרים את בעיה א' ולאחר מכן מפרסמים גרסה חדשה של
באפליקציה שלך.
Crashlytics מקבל דיווח נוסף על בעיה 'א' אחרי שסגרתם את הבעיה.
אם הדוח מגיע מגרסת אפליקציה שה-Crashlyticsיודע/ת עליה
כשסגרת את הבעיה (כלומר, הגרסה שלחה קריסה
דיווח על קריסה כלשהי בכלל), ואז Crashlytics לא יתייחס לקריסה
בחזרה למצב הקודם. הבעיה תישאר סגורה.
אם הדוח מגיע מגרסה של האפליקציה ש-Crashlyticsלא ידעה עליה כשסגרתם את הבעיה (כלומר, הגרסה אף פעם לא שלחה אף דוח קריסה לגבי קריסה כלשהי), Crashlytics תתייחס לבעיה כאל חזרה לאחור ותפתח מחדש את הבעיה.
כשבעיה חוזרת, אנחנו שולחים התראה על זיהוי רגרסיה ומוסיפים לבעיה אות רגרסיה כדי להודיע לכם ש-Crashlytics פתח אותה מחדש. אם אתם לא רוצים שהבעיה תיפתח מחדש בגלל אלגוריתם הרגרסיה שלנו, תוכלו להשתיק אותה במקום לסגור אותה.
למה אני רואה מצב של רגרסיה
בעיות בגרסאות ישנות יותר של האפליקציה?
אם הדיווח מגיע מגרסה ישנה של האפליקציה שמעולם לא שלחה דוחות קריסה בכלל כשסגרתם את הבעיה, Crashlytics תתייחס לבעיה כאל חזרה לאחור ותפתח אותה מחדש.
מצב זה יכול להתרחש במצב הבא: תיקנת באג ולאחר מכן
פרסמה גרסה חדשה של האפליקציה, אבל עדיין יש לך משתמשים בגרסאות ישנות יותר
ללא תיקון הבאג. אם במקרה אחת מהגרסאות הישנות האלה אף פעם לא שלחה דוחות קריסה כשסגרתם את הבעיה, והמשתמשים האלה מתחילים להיתקל בבאג, דוחות הקריסה האלה יגרמו לבעיה של נסיגה לאחור.
אם אתם לא רוצים שהבעיה תיפתח מחדש בגלל אלגוריתם הרגרסיה שלנו, תוכלו להשתיק אותה במקום לסגור אותה.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2024-10-16 (שעון UTC)."],[],[]]