عیب یابی Crashlytics و سوالات متداول

عدم مشاهده کاربران بدون خرابی، گزارش‌های خرده نان، و/یا هشدارهای سرعت

اگر کاربران بدون خرابی، گزارش‌های خرده نان، و/یا هشدارهای سرعت را نمی‌بینید، توصیه می‌کنیم پیکربندی برنامه خود را برای Google Analytics بررسی کنید.

• مطمئن شوید که Google Analytics را در پروژه Firebase خود فعال کرده اید.

• مطمئن شوید که اشتراک گذاری داده برای Google Analytics در صفحه Integrations > Google Analytics کنسول Firebase فعال باشد. توجه داشته باشید که تنظیمات اشتراک گذاری داده در کنسول Firebase نمایش داده می شود اما در کنسول Google Analytics مدیریت می شود.

• علاوه بر Firebase Crashlytics SDK، مطمئن شوید که Firebase SDK برای Google Analytics را به برنامه خود اضافه کرده اید ( iOS+ | Android ).

• مطمئن شوید که از جدیدترین نسخه ها برای همه SDK های Firebase ( iOS+ | Android ) استفاده می کنید.
  به خصوص بررسی کنید که حداقل از نسخه های زیر Firebase SDK برای Google Analytics استفاده می کنید: iOS+ — نسخه 6.3.1+ (نسخه 8.9.0+ برای macOS و tvOS) | Android — نسخه 17.2.3+ (BoM v24.7.1+) .

چرا ANR ها فقط برای Android 11+ گزارش می شوند؟

Crashlytics از گزارش ANR برای برنامه‌های Android از دستگاه‌هایی که Android 11 و بالاتر را اجرا می‌کنند، پشتیبانی می‌کند. API اصلی که برای جمع‌آوری ANR استفاده می‌کنیم ( getHistoricalProcessExitReasons ) قابل اعتمادتر از SIGQUIT یا رویکردهای مبتنی بر نظارت است. این API فقط در دستگاه‌های Android 11 و بالاتر در دسترس است.

تفاوت بین گزارش‌های ANR در داشبورد Crashlytics و کنسول Google Play

ممکن است بین تعداد ANR بین Google Play و Crashlytics ناهماهنگی وجود داشته باشد. این به دلیل تفاوت در مکانیسم جمع آوری و گزارش داده های ANR انتظار می رود. Crashlytics هنگام راه‌اندازی بعدی برنامه، ANR را گزارش می‌کند، در حالی که Android Vitals داده‌های ANR را پس از وقوع ANR ارسال می‌کند.

علاوه بر این، Crashlytics فقط ANR‌هایی را که در دستگاه‌های دارای Android نسخه ۱۱ و بالاتر رخ می‌دهند، در مقایسه با Google Play که ANR‌های دستگاه‌های دارای سرویس‌های Google Play و رضایت جمع‌آوری داده‌ها را نشان می‌دهد، نمایش می‌دهد.

تفاوت بین ردیابی پشته NDK در داشبورد Crashlytics و logcat

زنجیره‌های ابزار LLVM و GNU پیش‌فرض‌ها و درمان‌های متمایزی برای بخش فقط خواندنی باینری‌های برنامه شما دارند، که ممکن است ردیابی پشته‌ای ناسازگار در کنسول Firebase ایجاد کند. برای کاهش این مشکل، پرچم‌های پیوند دهنده زیر را به فرآیند ساخت خود اضافه کنید:

• اگر از پیوند دهنده lld از زنجیره ابزار LLVM استفاده می کنید، اضافه کنید:

  -Wl,--no-rosegment
  

• اگر از پیوند دهنده ld.gold از زنجیره ابزار گنو استفاده می کنید، اضافه کنید:

  -Wl,--rosegment
  

اگر همچنان ناهماهنگی های stack trace را مشاهده می کنید (یا اگر هیچ کدام از پرچم ها مربوط به زنجیره ابزار شما نیست)، به جای آن موارد زیر را به فرآیند ساخت خود اضافه کنید:

-fno-omit-frame-pointer

چگونه می توانم از باینری تولید کننده فایل نماد Breakpad خود برای NDK استفاده کنم؟

افزونه Crashlytics یک تولید کننده فایل نماد Breakpad سفارشی را باندل می کند. اگر ترجیح می‌دهید از باینری خود برای تولید فایل‌های نماد Breakpad استفاده کنید (به عنوان مثال، اگر ترجیح می‌دهید همه فایل‌های اجرایی بومی در زنجیره ساخت خود را از منبع بسازید)، از ویژگی انتخابی پسوند symbolGeneratorBinary برای تعیین مسیر فایل اجرایی استفاده کنید.

می توانید مسیر دودویی تولید کننده فایل نماد Breakpad را به یکی از دو روش مشخص کنید:

• گزینه 1 : مسیر را از طریق پسوند firebaseCrashlytics در فایل build.gradle خود مشخص کنید.

  موارد زیر را به فایل build.gradle در سطح برنامه خود اضافه کنید:

  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.symbolGeneratorBinary برای تعیین مسیر فایل اجرایی استفاده کنید.

  شما می توانید به صورت دستی فایل ویژگی های Gradle خود را به روز کنید یا فایل را از طریق خط فرمان به روز کنید. به عنوان مثال، برای تعیین مسیر از طریق خط فرمان، از دستوری مانند زیر استفاده کنید:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

کرش نکردن با Dexguard

اگر استثنای زیر را مشاهده کردید، احتمالاً از نسخه‌ای از DexGuard استفاده می‌کنید که با Firebase Crashlytics SDK ناسازگار است:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

این استثنا برنامه شما را خراب نمی‌کند، اما از ارسال گزارش‌های خرابی جلوگیری می‌کند. برای رفع این مشکل:

1. مطمئن شوید که از آخرین نسخه DexGuard 8.x استفاده می کنید. آخرین نسخه حاوی قوانینی است که توسط Firebase Crashlytics SDK مورد نیاز است.

2. اگر نمی خواهید نسخه DexGuard خود را تغییر دهید، سعی کنید خط زیر را به قوانین مبهم سازی خود (در فایل پیکربندی DexGuard خود) اضافه کنید:

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

چرا من خرابی فایل‌های .kt را می‌بینم که به‌عنوان مسائل .java برچسب‌گذاری شده‌اند؟

هنگامی که یک برنامه از یک مبهم کننده استفاده می کند که پسوند فایل را نشان نمی دهد، Crashlytics به طور پیش فرض هر مشکل را با پسوند فایل .java ایجاد می کند.

برای اینکه Crashlytics بتواند مشکلاتی با پسوند فایل درست ایجاد کند، مطمئن شوید که برنامه شما از تنظیمات زیر استفاده می‌کند:

• از اندروید Gradle 4.2.0 یا بالاتر استفاده می کند
• از R8 با مبهم سازی روشن استفاده می کند. برای به‌روزرسانی برنامه خود به R8، این مستندات را دنبال کنید.

توجه داشته باشید که پس از به‌روزرسانی به تنظیماتی که در بالا توضیح داده شد، ممکن است مشکلات .kt جدید را مشاهده کنید که تکراری از مشکلات .java . موجود هستند. برای کسب اطلاعات بیشتر در مورد آن شرایط، پرسش‌های متداول را ببینید.

چرا من مسائل .kt را می بینم که تکراری از مسائل .java موجود هستند؟

از اواسط دسامبر 2021، Crashlytics پشتیبانی از برنامه‌هایی را که از Kotlin استفاده می‌کنند، بهبود بخشید.

تا همین اواخر، مبهم‌کننده‌های موجود پسوند فایل را آشکار نمی‌کردند، بنابراین Crashlytics به طور پیش‌فرض هر مشکل را با پسوند فایل .java ایجاد می‌کرد. با این حال، از اندروید Gradle 4.2.0، R8 از پسوندهای فایل پشتیبانی می کند.

با این به‌روزرسانی، Crashlytics اکنون می‌تواند تعیین کند که آیا هر کلاسی که در برنامه استفاده می‌شود در Kotlin نوشته شده است یا خیر و نام فایل صحیح را در امضای شماره قرار دهد. اگر برنامه شما دارای تنظیمات زیر باشد، خرابی‌ها اکنون به درستی به فایل‌های .kt . نسبت داده می‌شوند (در صورت لزوم):

• برنامه شما از Android Gradle 4.2.0 یا بالاتر استفاده می کند.
• برنامه شما از R8 با مبهم سازی روشن استفاده می کند.

از آنجایی که خرابی‌های جدید اکنون شامل پسوند فایل صحیح در امضای مشکل خود می‌شوند، ممکن است مشکلات .kt جدیدی را مشاهده کنید که در واقع فقط تکراری از مشکلات موجود با برچسب .java هستند. در کنسول Firebase، ما سعی می‌کنیم اگر یک مشکل .kt جدید تکراری احتمالی یک مشکل با برچسب جاوای موجود باشد، شناسایی کنیم و با شما در میان .java .

کاربران بدون خرابی چگونه محاسبه می شوند؟

مقدار بدون خرابی نشان‌دهنده درصد کاربرانی است که با برنامه شما درگیر بوده‌اند اما در یک بازه زمانی خاص دچار خرابی نشده‌اند .

در اینجا فرمول محاسبه درصد کاربران بدون خرابی آمده است. مقادیر ورودی آن توسط Google Analytics ارائه می شود.

CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100

• وقتی خرابی رخ می‌دهد، Google Analytics یک نوع رویداد app_exception ارسال می‌کند و CRASHED_USERS تعداد کاربران مرتبط با آن نوع رویداد را نشان می‌دهد.

• ALL_USERS تعداد کل کاربرانی را نشان می‌دهد که در طول دوره زمانی که شما از منوی کشویی در سمت راست بالای داشبورد Crashlytics انتخاب کرده‌اید، با برنامه شما درگیر شده‌اند.

درصد کاربران بدون خرابی یک تجمع در طول زمان است، نه میانگین.

برای مثال، تصور کنید برنامه شما سه کاربر دارد. ما آنها را User A، User B و User C می نامیم. جدول زیر نشان می دهد که چه کاربرانی هر روز با برنامه شما درگیر بوده اند و کدام یک از آن کاربران در آن روز خراب شده اند:

• در روز چهارشنبه، درصد کاربران بدون خرابی شما 50٪ است (از هر 2 کاربر، 1 کاربر بدون خرابی بود).
  دو نفر از کاربران شما روز چهارشنبه با برنامه شما درگیر شدند، اما تنها یکی از آنها (کاربر B) هیچ خرابی نداشت.

• در 2 روز گذشته، درصد کاربران بدون خرابی شما 33.3٪ است (از هر 3 کاربر، 1 کاربر بدون خرابی بود).
  سه نفر از کاربران شما در دو روز گذشته با برنامه شما درگیر بودند، اما فقط یکی از آنها (کاربر C) هیچ خرابی نداشت.

• در 3 روز گذشته، درصد کاربران بدون خرابی شما 0٪ است (0 کاربر از 3 کاربر بدون خرابی بودند).
  سه نفر از کاربران شما در سه روز گذشته با برنامه شما درگیر بوده اند، اما هیچ کدام از آنها هیچ خرابی نداشته اند.

چه کسی می‌تواند یادداشت‌های مربوط به یک مشکل را مشاهده، بنویسد و حذف کند؟

یادداشت ها به اعضای پروژه اجازه می دهد تا در مورد مسائل خاص با سؤالات، به روز رسانی وضعیت و غیره نظر دهند.

هنگامی که یک عضو پروژه یادداشتی را پست می کند، با ایمیل حساب Google خود برچسب گذاری می شود. این آدرس ایمیل همراه با یادداشت برای همه اعضای پروژه که به مشاهده یادداشت دسترسی دارند قابل مشاهده است.

موارد زیر دسترسی مورد نیاز برای مشاهده، نوشتن و حذف یادداشت ها را شرح می دهد:

• اعضای پروژه با هر یک از نقش‌های زیر می‌توانند یادداشت‌های موجود را مشاهده و حذف کنند و یادداشت‌های جدیدی در مورد یک موضوع بنویسند.

  • مالک یا ویرایشگر پروژه، مدیر Firebase ، سرپرست کیفیت ، یا سرپرست Crashlytics

• اعضای پروژه با هر یک از نقش های زیر می توانند یادداشت های ارسال شده در مورد یک موضوع را مشاهده کنند، اما نمی توانند یادداشتی را حذف یا بنویسند.

  • Project Viewer ، Firebase Viewer ، Quality Viewer یا Crashlytics Viewer

برنامه همچنین از Google Mobile Ads SDK استفاده می‌کند اما خراب نمی‌شود

اگر پروژه شما از Crashlytics در کنار Google Mobile Ads SDK استفاده می کند، احتمالاً گزارشگران خرابی هنگام ثبت کنترل کننده های استثنا دخالت می کنند. برای رفع مشکل، با تماس با disableSDKCrashReporting ، گزارش خرابی را در SDK تبلیغات موبایل خاموش کنید.

مجموعه داده BigQuery من در کجا قرار دارد؟

پس از اینکه Crashlytics را به BigQuery پیوند دادید، مجموعه داده‌های جدیدی که ایجاد می‌کنید به‌طور خودکار در ایالات متحده قرار می‌گیرند، بدون در نظر گرفتن مکان پروژه Firebase شما.

آیا Crashlytics از armeabi پشتیبانی می کند؟

Firebase Crashlytics NDK از ARMv5 (armeabi) پشتیبانی نمی کند. پشتیبانی از این ABI از NDK r17 حذف شد.

موضوع پسرفته چیست؟

زمانی که شما قبلاً آن را بسته اید، یک مشکل پسرفت داشته است، اما Crashlytics گزارش جدیدی دریافت می کند مبنی بر اینکه مشکل دوباره رخ داده است. Crashlytics به طور خودکار این مشکلات پسرفته را مجدداً باز می کند تا بتوانید آنها را مطابق با برنامه خود برطرف کنید.

در اینجا یک سناریوی مثال آمده است که توضیح می دهد چگونه Crashlytics یک موضوع را به عنوان یک رگرسیون طبقه بندی می کند:

1. برای اولین بار، Crashlytics یک گزارش خرابی در مورد Crash "A" دریافت می کند. Crashlytics یک مشکل مربوط به آن خرابی را باز می کند (مسئله "A").
2. این باگ را به سرعت برطرف می‌کنید، شماره A را می‌بندید و سپس نسخه جدیدی از برنامه خود را منتشر می‌کنید.
3. Crashlytics پس از بسته شدن این موضوع، گزارش دیگری در مورد مسئله "A" دریافت می کند.
   • اگر گزارش مربوط به نسخه برنامه‌ای است که Crashlytics هنگام بستن مشکل از آن مطلع بوده است (به این معنی که نسخه اصلاً گزارش خرابی را برای هر خرابی ارسال کرده است)، Crashlytics این مشکل را پسرفته در نظر نخواهد گرفت. موضوع بسته خواهد ماند.
   • اگر گزارش مربوط به نسخه برنامه‌ای است که Crashlytics از آن اطلاعی نداشته است (به این معنی که نسخه هرگز گزارش خرابی برای هر خرابی ارسال نکرده است)، Crashlytics مشکل را پسرفت‌شده در نظر می‌گیرد و دوباره آن را باز می‌کند. .

وقتی مشکلی پسرفت می‌کند، یک هشدار تشخیص رگرسیون ارسال می‌کنیم و یک سیگنال رگرسیون به مشکل اضافه می‌کنیم تا به شما اطلاع دهیم که Crashlytics دوباره مشکل را باز کرده است. اگر به دلیل الگوریتم رگرسیون ما نمی خواهید مشکلی دوباره باز شود، به جای بستن آن، آن را "بی صدا" کنید.

چرا من مشکلات پسرفته را برای نسخه های قدیمی برنامه می بینم؟

اگر گزارشی از یک نسخه برنامه قدیمی است که در هنگام بسته شدن مشکل، هیچ گزارش خرابی ارسال نکرده است، Crashlytics مشکل را پسرفته می‌داند و دوباره آن را باز می‌کند.

این وضعیت می‌تواند در شرایط زیر اتفاق بیفتد: شما یک اشکال را برطرف کرده‌اید و نسخه جدیدی از برنامه خود را منتشر کرده‌اید، اما همچنان کاربرانی در نسخه‌های قدیمی‌تر بدون رفع اشکال دارید. اگر به‌طور تصادفی، یکی از آن نسخه‌های قدیمی‌تر هیچ‌وقت هیچ گزارش خرابی ارسال نکرده بود، و آن کاربران شروع به مواجهه با باگ کردند، آن گزارش‌های خرابی باعث ایجاد یک مشکل پسرفته می‌شوند.

اگر به دلیل الگوریتم رگرسیون ما نمی خواهید مشکلی دوباره باز شود، به جای بستن آن، آن را "بی صدا" کنید.