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

مشاهده‌ی قالب‌های مختلف (و گاهی اوقات «انواع») برای برخی از مسائل در جدول مسائل

ممکن است متوجه دو فرمت مختلف برای مشکلات ذکر شده در جدول مشکلات خود در کنسول Firebase شوید. و همچنین ممکن است متوجه ویژگی‌ای به نام "انواع" در برخی از مشکلات خود شوید. دلیل آن این است!

در اوایل سال ۲۰۲۳، ما یک موتور تحلیل بهبود یافته برای گروه‌بندی رویدادها و همچنین یک طراحی به‌روز شده و برخی ویژگی‌های پیشرفته برای مسائل جدید (مانند انواع مختلف!) را ارائه دادیم. برای جزئیات بیشتر، به پست وبلاگ اخیر ما مراجعه کنید، اما می‌توانید نکات برجسته را در زیر بخوانید.

Crashlytics تمام رویدادهای برنامه شما (مانند خرابی‌ها، خطاهای غیرفاجعه‌آمیز و ANRها) را تجزیه و تحلیل می‌کند و گروه‌هایی از رویدادها به نام مشکلات (issues ) ایجاد می‌کند - همه رویدادهای یک مشکل (issue) یک نقطه شکست مشترک دارند.

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

با این حال، در این گروه از رویدادها، ممکن است ردپاهای پشته منجر به خرابی متفاوت باشند. یک ردپای پشته متفاوت می‌تواند به معنای علت ریشه‌ای متفاوت باشد. برای نمایش این تفاوت احتمالی در یک مسئله، اکنون انواعی را در مسائل ایجاد می‌کنیم - هر نوع، زیرگروهی از رویدادها در یک مسئله است که نقطه خرابی یکسانی دارند و یک ردپای پشته مشابه. با انواع، می‌توانید رایج‌ترین ردپاهای پشته را در یک مسئله اشکال‌زدایی کنید و تعیین کنید که آیا علل ریشه‌ای متفاوتی منجر به خرابی می‌شوند یا خیر.

در اینجا چیزی است که با این پیشرفت‌ها تجربه خواهید کرد:

• فراداده‌های اصلاح‌شده در ردیف مشکل نمایش داده می‌شوند
  اکنون درک و اولویت‌بندی مشکلات در برنامه شما آسان‌تر است.

• مسائل تکراری کمتر
  تغییر شماره خط منجر به مشکل جدیدی نمی‌شود.

• اشکال‌زدایی آسان‌تر مسائل پیچیده با علل ریشه‌ای مختلف
  از انواع مختلف برای اشکال‌زدایی رایج‌ترین ردپاهای پشته در یک مسئله استفاده کنید.

• هشدارها و سیگنال‌های معنادارتر
  یک مشکل جدید در واقع نشان دهنده یک باگ جدید است.

• جستجوی قدرتمندتر
  هر شماره شامل فراداده‌های قابل جستجوی بیشتری مانند نوع استثنا و نام بسته است.

نحوه‌ی اعمال این بهبودها به شرح زیر است:

• وقتی رویدادهای جدیدی از برنامه شما دریافت می‌کنیم، بررسی می‌کنیم که آیا با مشکل موجود مطابقت دارند یا خیر.

• اگر هیچ تطابقی وجود نداشته باشد، ما به طور خودکار الگوریتم گروه‌بندی رویداد هوشمندتر خود را برای رویداد اعمال می‌کنیم و یک issue جدید با طراحی فراداده اصلاح‌شده ایجاد می‌کنیم.

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

عدم مشاهده لاگ‌های breadcrumb

اگر گزارش‌های breadcrumb را مشاهده نمی‌کنید ( iOS+ | Android | Flutter | Unity )، توصیه می‌کنیم پیکربندی برنامه خود را برای Google Analytics بررسی کنید. مطمئن شوید که شرایط زیر را برآورده می‌کنید:

• شما Google Analytics در پروژه فایربیس خود فعال کرده‌اید .

• شما اشتراک‌گذاری داده‌ها را برای Google Analytics فعال کرده‌اید. برای اطلاعات بیشتر در مورد این تنظیم، به مدیریت تنظیمات اشتراک‌گذاری داده‌های آنالیتیکس خود مراجعه کنید.

• شما کیت توسعه نرم‌افزار Firebase برای Google Analytics را به برنامه خود اضافه کرده‌اید: iOS+ | اندروید | فلاتر | یونیتی .
  این SDK باید علاوه بر Crashlytics SDK اضافه شود.

• شما از آخرین نسخه‌های Firebase SDK برای تمام محصولاتی که در برنامه خود استفاده می‌کنید ( iOS+ | Android | Flutter | Unity ) استفاده می‌کنید.

  برای پلتفرم‌های اپل و برنامه‌های اندروید، به خصوص بررسی کنید که حداقل از نسخه زیر از Firebase SDK برای Google Analytics استفاده می‌کنید: iOS+ — نسخه ۶.۳.۱+ (نسخه ۸.۹.۰+ برای macOS و tvOS) | اندروید — نسخه 17.2.3+ ( BoM v24.7.1+).

عدم مشاهده هشدارهای سرعت

اگر هشدارهای سرعت را نمی‌بینید، مطمئن شوید که از ... استفاده می‌کنید.

عدم مشاهده معیارهای بدون خرابی (یا مشاهده معیارهای غیرقابل اعتماد)

اگر معیارهای بدون خرابی (مانند کاربران و جلسات بدون خرابی) را نمی‌بینید یا معیارهای غیرقابل اعتمادی را می‌بینید، موارد زیر را بررسی کنید:

• مطمئن شوید که از ... استفاده می‌کنید

• مطمئن شوید که تنظیمات جمع‌آوری داده‌های شما بر کیفیت معیارهای بدون خرابی شما تأثیر نمی‌گذارد:

  • اگر با غیرفعال کردن گزارش خودکار خرابی، گزارش‌دهی اختیاری را فعال کنید ، اطلاعات خرابی فقط از کاربرانی که صریحاً در جمع‌آوری داده‌ها مشارکت داشته‌اند، می‌تواند به Crashlytics ارسال شود. بنابراین، دقت معیارهای بدون خرابی تحت تأثیر قرار خواهد گرفت زیرا Crashlytics فقط اطلاعات خرابی این کاربران انتخابی (و نه همه کاربران شما) را دارد. این بدان معناست که معیارهای بدون خرابی شما ممکن است کمتر قابل اعتماد باشند و کمتر نشان‌دهنده پایداری کلی برنامه شما باشند.

  • اگر جمع‌آوری خودکار داده‌ها را غیرفعال کرده‌اید، می‌توانید sendUnsentReports برای ارسال گزارش‌های ذخیره‌شده روی دستگاه به Crashlytics استفاده کنید. استفاده از این روش، داده‌های خرابی را به Crashlytics ارسال می‌کند، اما داده‌های جلسات را نه، که باعث می‌شود نمودارهای کنسول مقادیر کم یا صفر را برای معیارهای بدون خرابی نشان دهند.

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

به بخش «معیارهای بدون خرابی را درک کنید» مراجعه کنید.

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

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

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

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

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

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

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

  • نمایشگر پروژه، نمایشگر فایربیس ، نمایشگر کیفیت یا نمایشگر Crashlytics

مسئله‌ی پس‌رفته چیست؟

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

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

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

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

چرا مشکلات مربوط به نسخه‌های قدیمی‌تر برنامه را می‌بینم؟

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

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

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

dSYM ها گم شده اند/آپلود نمی شوند

برای آپلود dSYM های پروژه خود و دریافت خروجی واضح، موارد زیر را بررسی کنید:

1. مطمئن شوید که مرحله ساخت پروژه شما شامل اسکریپت اجرای Crashlytics است، که به Xcode اجازه می‌دهد dSYM های پروژه شما را در زمان ساخت آپلود کند (برای دستورالعمل‌های افزودن اسکریپت، بخش «راهنمای اولیه Crashlytics را مطالعه کنید). پس از به‌روزرسانی پروژه، یک کرش اجباری ایجاد کنید و تأیید کنید که کرش در داشبورد Crashlytics ظاهر می‌شود.

2. اگر در کنسول Firebase هشدار "Missing dSYM" را مشاهده کردید، Xcode را بررسی کنید تا مطمئن شوید که dSYM های لازم برای ساخت را به درستی تولید می‌کند .

3. اگر Xcode به درستی dSYM ها را تولید می‌کند، و شما هنوز dSYM های از دست رفته را می‌بینید، احتمالاً ابزار اجرای اسکریپت هنگام آپلود dSYM ها گیر کرده است. در این حالت، هر یک از موارد زیر را امتحان کنید:

   • مطمئن شوید که از آخرین نسخه Crashlytics استفاده می‌کنید.

   • فایل‌های dSYM مفقود شده را به صورت دستی آپلود کنید:

     • گزینه ۱: از گزینه «کشیدن و رها کردن» مبتنی بر کنسول در تب dSYMs برای آپلود یک آرشیو زیپ حاوی فایل‌های dSYM مفقود شده استفاده کنید.
     • گزینه ۲: از اسکریپت upload-symbols برای آپلود فایل‌های dSYM مفقود شده، برای UUID های ارائه شده در تب dSYMs، استفاده کنید.

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

تصادفات به خوبی نمادین‌سازی نشده‌اند

اگر به نظر می‌رسد که نشانه‌های پشته شما به خوبی نمادین‌سازی نشده‌اند، موارد زیر را بررسی کنید:

• اگر فریم‌های کتابخانه برنامه شما فاقد ارجاع به کد برنامه هستند، مطمئن شوید که -fomit-frame-pointer به عنوان یک پرچم کامپایل تنظیم نشده است.

• اگر چندین فریم (Missing) برای کتابخانه برنامه خود مشاهده می‌کنید، بررسی کنید که آیا dSYM های اختیاری به عنوان گم‌شده (برای نسخه برنامه آسیب‌دیده) در برگه dSYM های Crashlytics در کنسول Firebase وجود دارد یا خیر. در این صورت، مرحله عیب‌یابی "هشدار dSYM گم‌شده" را در بخش سوالات متداول dSYM های گم‌شده/ آپلود نشده در این صفحه دنبال کنید. توجه داشته باشید که آپلود این dSYM ها، خرابی‌هایی را که قبلاً رخ داده‌اند، نمادین نمی‌کند، اما این به تضمین نمادین‌سازی برای خرابی‌های آینده کمک می‌کند.

آیا می‌توانم Crashlytics برای macOS یا tvOS استفاده کنم؟

بله، می‌توانید Crashlytics در پروژه‌های macOS و tvOS پیاده‌سازی کنید. مطمئن شوید که نسخه ۸.۹.۰+ از Firebase SDK for Google Analytics را شامل می‌شود تا خرابی‌ها به معیارهای جمع‌آوری‌شده توسط Google Analytics (کاربران بدون خرابی، آخرین نسخه، هشدارهای سرعت و گزارش‌های breadcrumb) دسترسی داشته باشند.

آیا می‌توانم Crashlytics در یک پروژه Firebase با چندین برنامه در پلتفرم‌های مختلف اپل استفاده کنم؟

اکنون می‌توانید خرابی‌ها را برای چندین برنامه در یک پروژه Firebase گزارش دهید، حتی زمانی که برنامه‌ها برای پلتفرم‌های مختلف اپل (مثلاً iOS، tvOS و Mac Catalyst) ساخته شده‌اند. پیش از این، اگر برنامه‌ها دارای شناسه بسته یکسانی بودند، باید آنها را به پروژه‌های Firebase جداگانه تقسیم می‌کردید.

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

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

چرا بعضی از ANR ها BuildId خود را ندارند؟

اگر برخی از ANR های شما BuildId های خود را ندارند، به روش زیر عیب یابی کنید:

• مطمئن شوید که از نسخه به‌روز Crashlytics Android SDK و افزونه Crashlytics Gradle استفاده می‌کنید.

  اگر BuildId های اندروید ۱۱ و برخی از ANR های اندروید ۱۲ را ندارید، احتمالاً از SDK، افزونه Gradle یا هر دوی آنها استفاده می‌کنید که قدیمی هستند. برای جمع‌آوری صحیح BuildId های این ANR ها، باید از نسخه‌های زیر استفاده کنید:

  • Crashlytics Android SDK نسخه ۱۸.۳.۵+ ( Firebase BoM نسخه ۳۱.۲.۲+)
  • افزونه Crashlytics Gradle نسخه ۲.۹.۴+

• بررسی کنید که آیا از مکان غیر استانداردی برای کتابخانه‌های اشتراکی خود استفاده می‌کنید یا خیر.

  اگر فقط BuildId های کتابخانه‌های اشتراکی برنامه‌تان را ندارید، احتمالاً از مکان استاندارد و پیش‌فرض برای کتابخانه‌های اشتراکی استفاده نمی‌کنید. در این صورت، Crashlytics ممکن است نتواند BuildId مرتبط را پیدا کند. توصیه می‌کنیم از مکان استاندارد برای کتابخانه‌های اشتراکی استفاده کنید.

• مطمئن شوید که BuildId را در طول فرآیند ساخت حذف نمی‌کنید.

  توجه داشته باشید که نکات عیب‌یابی زیر هم برای ANRها و هم برای خرابی‌های بومی (native crashes) کاربرد دارند.

  • با اجرای readelf -n روی فایل‌های باینری خود، وجود BuildId را بررسی کنید. اگر BuildId ها وجود ندارند، -Wl,--build-id را به پرچم‌های سیستم ساخت خود اضافه کنید.

  • بررسی کنید که ناخواسته برای کاهش حجم APK، BuildId ها را حذف نکنید.

  • اگر نسخه‌های ساده و بدون تغییر یک کتابخانه را نگه می‌دارید، حتماً در کد خود به نسخه صحیح اشاره کنید.

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

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

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

چرا شاهد خرابی‌هایی از فایل‌های .kt هستم که با برچسب مشکلات .java مشخص شده‌اند؟

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

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

• از اندروید Gradle نسخه ۴.۲.۰ یا بالاتر استفاده می‌کند
• از R8 با قابلیت مبهم‌سازی فعال استفاده می‌کند. برای به‌روزرسانی برنامه خود به R8، این مستندات را دنبال کنید.

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

چرا مشکلات .kt را می‌بینم که کپی مشکلات .java موجود هستند؟

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

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

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

• برنامه شما از اندروید Gradle نسخه ۴.۲.۰ یا بالاتر استفاده می‌کند.
• برنامه شما از R8 با قابلیت مبهم‌سازی فعال استفاده می‌کند.

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

عدم خرابی با Dexguard

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

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

چگونه افزونه Gradle را به نسخه ۳ Crashlytics ارتقا دهیم؟

آخرین نسخه افزونه Crashlytics Gradle یک نسخه اصلی (v3.0.0) است و با حذف پشتیبانی از نسخه‌های پایین‌تر Gradle و افزونه Android Gradle، SDK را مدرن می‌کند. علاوه بر این، تغییرات این نسخه مشکلات AGP نسخه ۸.۱+ را برطرف کرده و پشتیبانی از برنامه‌های بومی و نسخه‌های سفارشی را بهبود می‌بخشد.

حداقل الزامات

افزونه Crashlytics Gradle نسخه ۳ حداقل الزامات زیر را دارد:

• افزونه Gradle اندروید نسخه ۸.۱+
  این افزونه را با استفاده از دستیار ارتقاء افزونه Android Gradle در آخرین نسخه Android Studio ارتقا دهید.

• افزونه Gradle google-services فایربیس نسخه ۴.۴.۱+
  این افزونه را با مشخص کردن آخرین نسخه در فایل Gradle build پروژه خود، به صورت زیر ارتقا دهید:

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

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

تغییرات در افزونه‌ی Crashlytics

با نسخه ۳ افزونه 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 .

مثالی برای نحوه ارتقاء افزونه

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGenerator(
                closureOf<SymbolGenerator> {
                  symbolGeneratorType = "breakpad"
                  breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              )
            }
          }
        }
      

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGeneratorType = "breakpad"
              breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGenerator {
                breakpad {
                  binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              }
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

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

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

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

  -Wl,--no-rosegment

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

  -Wl,--rosegment

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

-fno-omit-frame-pointer

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

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

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

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

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

  افزونه 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")
            }
          }
        }
     }
  }

• گزینه ۲ : مسیر را از طریق یک خط ویژگی در فایل ویژگی‌های 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 حذف شده است.

مشاهده‌ی ردپاهای پشته‌ای بدون نمادگذاری برای برنامه‌های اندروید در داشبورد Crashlytics

اگر از Unity IL2CPP استفاده می‌کنید و ردپاهای پشته بدون نماد را مشاهده می‌کنید، موارد زیر را امتحان کنید:

1. مطمئن شوید که از نسخه ۸.۶.۱ یا بالاتر Crashlytics Unity SDK استفاده می‌کنید.

2. مطمئن شوید که برای تولید و آپلود فایل نماد خود، دستور crashlytics:symbols:upload در Firebase CLI را تنظیم و اجرا کرده‌اید.

   شما باید هر بار که یک نسخه آزمایشی یا هر نسخه‌ای که می‌خواهید ردپاهای پشته نمادین آن را در کنسول Firebase ببینید، ایجاد می‌کنید، این دستور CLI را اجرا کنید. برای کسب اطلاعات بیشتر به بخش «گزارش‌های خرابی خوانا» مراجعه کنید.

آیا می‌توان Crashlytics با برنامه‌هایی که از IL2CPP استفاده می‌کنند، استفاده کرد؟

بله، Crashlytics می‌تواند ردیابی‌های پشته نمادین را برای برنامه‌های شما که از IL2CPP استفاده می‌کنند، نمایش دهد. این قابلیت برای برنامه‌های منتشر شده در پلتفرم‌های اندروید یا اپل در دسترس است. در اینجا کاری که باید انجام دهید آمده است:

1. مطمئن شوید که از نسخه ۸.۶.۰ یا بالاتر Crashlytics Unity SDK استفاده می‌کنید.

2. وظایف لازم برای پلتفرم خود را انجام دهید:

   • برای برنامه‌های پلتفرم اپل : هیچ اقدام خاصی لازم نیست. برای برنامه‌های پلتفرم اپل، افزونه Firebase Unity Editor به طور خودکار پروژه Xcode شما را برای آپلود نمادها پیکربندی می‌کند.

   • برای برنامه‌های اندروید : مطمئن شوید که برای ایجاد و آپلود فایل نماد خود، دستور crashlytics:symbols:upload در Firebase CLI را تنظیم و اجرا کرده‌اید.

     شما باید هر بار که یک نسخه آزمایشی یا هر نسخه‌ای که می‌خواهید ردپاهای پشته نمادین آن را در کنسول Firebase ببینید، ایجاد می‌کنید، این دستور CLI را اجرا کنید. برای کسب اطلاعات بیشتر به بخش «گزارش‌های خرابی خوانا» مراجعه کنید.

چرا یک برنامه باید استثنائاتِ پیش‌بینی‌نشده را به عنوان خطای مهلک گزارش کند؟

با گزارش استثنائاتِ شناسایی‌نشده به عنوان مواردِ بحرانی، شما می‌توانید نشانه‌ی واقع‌بینانه‌تری از اینکه چه استثنائاتی ممکن است منجر به غیرقابل‌بازی شدن بازی شوند، حتی اگر برنامه همچنان به اجرا ادامه دهد، داشته باشید.

توجه داشته باشید که اگر شروع به گزارش تصادفات منجر به فوت کنید، احتمالاً درصد کاربران بدون تصادف (CFU) شما کاهش می‌یابد، اما معیار CFU بیشتر نمایانگر تجربیات کاربران نهایی با برنامه شما خواهد بود.

کدام موارد استثنا به عنوان فوتی گزارش خواهند شد؟

برای اینکه Crashlytics یک استثنای ناشناخته را به عنوان خطای مهلک گزارش کند، باید هر دو شرط زیر برقرار باشد:

• در طول مقداردهی اولیه برنامه، ویژگی ReportUncaughtExceptionsAsFatal باید روی true تنظیم شود .

• برنامه شما (یا یک کتابخانه شامل) یک استثنا را صادر می‌کند که دریافت نشده است. استثنایی که ایجاد شده است، اما دریافت نشده است ، به عنوان استثنای دریافت نشده در نظر گرفته نمی‌شود.

بعد از فعال کردن گزارش استثنائاتِ بررسی نشده به عنوان خطاهای مهلک، حالا خطاهای مهلک جدید زیادی دارم. چگونه می‌توانم این خطاها را به درستی مدیریت کنم؟

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

• در نظر بگیرید که چگونه می‌توانید شروع به دریافت و مدیریت این استثنائاتِ دریافت نشده کنید.
• گزینه‌های مختلفی را برای ثبت خطاها در کنسول اشکال‌زدایی Unity و Crashlytics در نظر بگیرید.

گرفتن و مدیریت استثنائات پرتاب شده

استثنائات برای انعکاس حالت‌های غیرمنتظره یا استثنایی ایجاد و ارسال می‌شوند. حل مشکلاتی که توسط یک استثنای ارسال شده منعکس می‌شوند، شامل بازگرداندن برنامه به حالت شناخته شده است (فرآیندی که به عنوان مدیریت استثنا شناخته می‌شود).

بهترین روش این است که تمام استثنائات پیش‌بینی‌شده را دریافت و مدیریت کنید، مگر اینکه برنامه را نتوان به حالت شناخته‌شده‌ای برگرداند.

برای کنترل اینکه کدام نوع استثنائات توسط چه کدی دریافت و مدیریت می‌شوند، کدی را که ممکن است استثنا ایجاد کند، در یک بلوک try-catch قرار دهید . مطمئن شوید که شرایط موجود در دستورات catch تا حد امکان محدود هستند تا استثنائات خاص را به طور مناسب مدیریت کنند.

ثبت خطاها در Unity یا Crashlytics

روش‌های مختلفی برای ثبت استثنائات در Unity یا Crashlytics وجود دارد تا به رفع اشکال کمک کند.

هنگام استفاده از Crashlytics ، دو گزینه رایج و توصیه‌شده در اینجا آمده است:

• گزینه ۱: در کنسول Unity چاپ کنید، اما در طول توسعه یا عیب‌یابی به Crashlytics گزارش ندهید

  • با استفاده از Debug.Log(exception) ، Debug.LogWarning(exception) و Debug.LogError(exception) که محتوای استثنا را در کنسول Unity چاپ می‌کنند و استثنا را دوباره پرتاب نمی‌کنند، در کنسول Unity چاپ کنید.

• گزینه ۲: برای گزارش‌های تلفیقی در داشبورد Crashlytics برای موقعیت‌های زیر، در Crashlytics آپلود کنید:

  • اگر یک استثنا ارزش ثبت شدن برای اشکال‌زدایی یک رویداد احتمالی بعدی Crashlytics را دارد، از Crashlytics.Log(exception.ToString()) استفاده کنید.
  • اگر یک استثنا، علیرغم شناسایی و مدیریت شدن، همچنان باید به Crashlytics گزارش شود، از Crashlytics.LogException(exception) برای ثبت آن به عنوان یک رویداد غیرمهلک استفاده کنید.

با این حال، اگر می‌خواهید یک رویداد مهلک را به صورت دستی به Unity Cloud Diagnostics گزارش دهید، می‌توانید از Debug.LogException استفاده کنید. این گزینه مانند گزینه ۱، استثنا را در کنسول Unity چاپ می‌کند، اما استثنا را نیز ارسال می‌کند (چه هنوز ارسال شده باشد و چه دریافت شده باشد). این خطا را به صورت غیر محلی ارسال می‌کند. این بدان معناست که حتی یک 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 استفاده می‌کند، احتمالاً گزارش‌دهنده‌های خرابی هنگام ثبت کنترل‌کننده‌های خطا تداخل ایجاد می‌کنند. برای رفع این مشکل، با فراخوانی disableSDKCrashReporting ، گزارش خرابی را در SDK Mobile Ads غیرفعال کنید.

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

فایربیس داده‌ها را به محل مجموعه داده‌ای که هنگام تنظیم صادرات داده به BigQuery انتخاب کرده‌اید، صادر می‌کند.

• این مکان هم برای مجموعه داده Crashlytics و هم برای مجموعه داده Sessions در Firebase (در صورتی که داده‌های Session برای خروجی گرفتن فعال باشد) اعمال می‌شود.

• این مکان فقط برای داده‌های صادر شده به BigQuery قابل استفاده است و تاثیری بر مکان داده‌های ذخیره شده برای استفاده در داشبورد Crashlytics کنسول Firebase یا در Android Studio ندارد.

• پس از ایجاد یک مجموعه داده، مکان آن قابل تغییر نیست، اما می‌توانید مجموعه داده را در مکان دیگری کپی کنید یا به صورت دستی مجموعه داده را در مکان دیگری جابجا (بازسازی) کنید. برای کسب اطلاعات بیشتر، به تغییر مکان برای صادرات موجود مراجعه کنید.

چگونه می‌توان زیرساخت صادرات جدید BigQuery را ارتقا داد؟

در اواسط اکتبر ۲۰۲۴، Crashlytics زیرساخت جدیدی را برای صادرات دسته‌ای داده‌های Crashlytics به BigQuery راه‌اندازی کرد.

• اگر بعد از اکتبر ۲۰۲۴ ، قابلیت صادرات دسته‌ای را فعال کرده باشید، پروژه Firebase شما به طور خودکار از زیرساخت صادرات جدید استفاده می‌کند و نیازی به انجام هیچ کاری نیست.

• اگر قبل یا در طول اکتبر ۲۰۲۴ ، صادرات دسته‌ای را فعال کرده‌اید، اطلاعات موجود در این سوالات متداول را بررسی کنید تا مشخص شود که آیا نیاز به انجام اقدامی دارید یا خیر.

تمام پروژه‌های فایربیس از ۹ ژانویه ۲۰۲۶ به طور خودکار به زیرساخت جدید صادرات دسته‌ای ارتقا خواهند یافت. می‌توانید قبل از این تاریخ ارتقا دهید ، اما مطمئن شوید که جداول دسته‌ای BigQuery شما پیش‌نیازهای ارتقا را برآورده می‌کنند.

مشخص کنید که آیا روی زیرساخت جدید هستید یا خیر

اگر صادرات دسته‌ای را در اواسط اکتبر ۲۰۲۴ یا بعد از آن فعال کرده باشید، پروژه Firebase شما به طور خودکار از زیرساخت صادرات جدید استفاده می‌کند.

می‌توانید بررسی کنید که پروژه شما از کدام زیرساخت استفاده می‌کند: به کنسول Google Cloud بروید و اگر "پیکربندی انتقال داده" شما با عنوان Firebase Crashlytics with Multi-Region Support برچسب‌گذاری شده باشد، پروژه شما از زیرساخت صادرات جدید استفاده می‌کند.

تفاوت‌های مهم بین زیرساخت‌های صادراتی قدیمی و زیرساخت‌های صادراتی جدید

• زیرساخت جدید از مجموعه داده‌های Crashlytics در مکان‌های خارج از ایالات متحده پشتیبانی می‌کند.

  • صادرات قبل از اواسط اکتبر ۲۰۲۴ فعال شده و به زیرساخت صادرات جدید ارتقا یافته است - اکنون می‌توانید به صورت اختیاری مکان صادرات داده‌ها را تغییر دهید .

  • فعال‌سازی صادرات در اواسط اکتبر ۲۰۲۴ یا بعد از آن — در هنگام راه‌اندازی از شما خواسته شد تا مکانی را برای صادرات داده‌ها انتخاب کنید.

• زیرساخت جدید از پر کردن مجدد داده‌های مربوط به قبل از فعال کردن قابلیت خروجی گرفتن پشتیبانی نمی‌کند.

  • زیرساخت قدیمی تا 30 روز قبل از تاریخی که شما صادرات را فعال کردید، از پر کردن مجدد پشتیبانی می‌کرد.

  • زیرساخت جدید از پر کردن مجدد داده‌ها تا 30 روز گذشته یا برای جدیدترین تاریخی که امکان صادرات به BigQuery را فعال کرده‌اید (هر کدام که جدیدتر باشد) پشتیبانی می‌کند.

• این زیرساخت جدید، جداول دسته‌ای BigQuery را با استفاده از شناسه‌های تعیین‌شده برای برنامه‌های Firebase شما در پروژه Firebase نامگذاری می‌کند.

  • زیرساخت قدیمی، داده‌ها را در جداول دسته‌ای با نام‌هایی بر اساس شناسه‌های بسته یا نام‌های بسته در فایل باینری برنامه شما می‌نوشت.

  • زیرساخت جدید، داده‌ها را در جداول دسته‌ای با نام‌هایی بر اساس شناسه‌های بسته یا نام‌های بسته تنظیم‌شده برای برنامه‌های Firebase ثبت‌شده شما در پروژه Firebase می‌نویسد.

مرحله ۱ : پیش‌نیازهای ارتقاء

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

   • می‌توانید تمام برنامه‌های Firebase ثبت‌شده در پروژه Firebase خود را در کنسول Firebase پیدا کنید: به settings پروژه خود بروید، سپس به کارت برنامه‌های خود بروید تا تمام برنامه‌های Firebase خود و اطلاعات آنها را مشاهده کنید.

   • شما می‌توانید تمام جداول دسته‌ای BigQuery خود را در صفحه BigQuery کنسول Google Cloud پیدا کنید.

   برای مثال، در اینجا ایالت‌های ایده‌آلی وجود دارد که در آنها مشکلی برای ارتقا نخواهید داشت:

   • شما یک جدول دسته‌ای به نام com_yourcompany_yourproject_IOS و یک برنامه Firebase iOS+ با شناسه بسته com.yourcompany.yourproject که در پروژه Firebase شما ثبت شده است، دارید.

   • شما یک جدول دسته‌ای به نام com_yourcompany_yourproject_ANDROID و یک برنامه اندروید Firebase با نام بسته com.yourcompany.yourproject در پروژه Firebase خود ثبت کرده‌اید.

2. اگر نام جدول‌های دسته‌ای شما با شناسه‌های تعیین‌شده برای برنامه‌های Firebase ثبت‌شده‌تان مطابقت ندارد ، قبل از به‌روزرسانی دستی یا قبل از 9 ژانویه 2026، دستورالعمل‌های بعدی در این صفحه را دنبال کنید تا از اختلال در خروجی دسته‌ای خود جلوگیری کنید.

مرحله ۲ : ارتقاء دستی به زیرساخت جدید

اگر قبل از اواسط اکتبر ۲۰۲۴، قابلیت صادرات دسته‌ای را فعال کرده باشید، می‌توانید به صورت دستی و با خاموش و روشن کردن صادرات داده‌های Crashlytics در کنسول Firebase ، زیرساخت جدید را ارتقا دهید.

در اینجا مراحل دقیق آمده است:

1. در کنسول Firebase ، به صفحه Integrations بروید.

2. در کارت BigQuery ، روی مدیریت (Manage) کلیک کنید.

3. برای غیرفعال کردن خروجی، نوار لغزنده Crashlytics را به حالت خاموش تغییر دهید. وقتی از شما خواسته شد، تأیید کنید که می‌خواهید خروجی داده‌ها متوقف شود.

4. بلافاصله دوباره نوار لغزنده Crashlytics را روشن کنید تا صادرات دوباره فعال شود. وقتی از شما خواسته شد، تأیید کنید که می‌خواهید داده‌ها را صادر کنید.

   اکنون داده‌های Crashlytics شما از طریق زیرساخت جدید به BigQuery منتقل می‌شوند.

نام جدول دسته‌ای فعلی شما با شناسه برنامه Firebase شما مطابقت ندارد