عیب‌یابی و پرسشگان Crashlytics

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

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

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

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

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

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

با این بهبودها، این موارد را تجربه خواهید کرد:

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

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

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

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

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

این بهبودها به این صورت عرضه می‌شوند:

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

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

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

گزارش‌های ردپای رخدادها را نمی‌بینید

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

• Google Analytics را در پروژه Firebase خود فعال کرده‌اید.

• هم‌رسانی داده را برای Google Analytics فعال کرده‌اید. درباره این تنظیم در مدیریت تنظیمات هم‌رسانی داده‌های Analytics بیشتر بدانید

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

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

  برای پلاتفرم‌های Apple و برنامه‌های Android، به‌ویژه بررسی کنید که حداقل از نسخه زیر کیت توسعه نرم‌افزار Firebase برای Google Analytics استفاده می‌کنید: iOS+ — v6.3.1+ (v8.9.0+ برای macOS و tvOS) | Android — v17.2.3+ (BoM v24.7.1+).

هشدارهای سرعت را نمی‌بینم

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

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

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

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

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

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

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

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

آشنایی با سنجه‌های بدون خرابی را ببینید.

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

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

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

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

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

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

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

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

مشکل پس‌رفت‌کرده چیست؟

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

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

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

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

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

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

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

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

dSYMها وجود ندارند/بارگذاری نمی‌شوند

برای بارگذاری dSYMهای پروژه‌تان و دریافت خروجی پرجزئیات، موارد زیر را بررسی کنید:

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

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

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

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

   • فایل‌های dSYM ناموجود را به‌صورت دستی بارگذاری کنید:

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

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

ازکارافتادگی‌ها به‌درستی نمادگذاری نشده‌اند

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

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

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

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

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

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

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

چرا خطاهای ANR فقط برای Android نسخه ۱۱ و بالاتر گزارش می‌شود؟

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

چرا برخی‌از خطاهای «برنامه پاسخ نمی‌دهد» BuildId ندارند؟

اگر برخی‌از ANRهای شما فاقد BuildId هستند، به‌صورت زیر عیب‌یابی کنید:

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

  اگر BuildIds برای Android 11 و برخی‌از خطاهای «Android پاسخ نمی‌دهد» در Android 12 را ندارید، احتمالاً از کیت توسعه نرم‌افزار، افزونه Gradle، یا هر دو قدیمی استفاده می‌کنید. برای جمع‌آوری صحیح BuildId برای این ANRها، باید از نسخه‌های زیر استفاده کنید:

  • Crashlytics کیت توسعه نرم‌افزار Android نسخه ۱۸.۳.۵+ (Firebase BoM نسخه ۳۱.۲.۲+)
  • Crashlytics افزایه Gradle نسخه ۲.۹.۴+

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

با Dexguard ازکارافتادگی دریافت نمی‌کنید

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

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

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

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

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

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

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

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

حداقل شرایط موردنیاز

Crashlytics Gradle plugin v3 دارای حداقل الزامات زیر است:

• افزایه Android Gradle نسخه ۸.۱ به بالا
  این افزایه را بااستفاده از دستیار ارتقای افزایه Android Gradle در جدیدترین نسخه Android Studio ارتقا دهید.

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

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

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

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

با نسخه ۳ افزایه Crashlytics Gradle، افزونه Crashlytics تغییرات مخرب زیر را دارد:

• افزونه از بلوک Android defaultConfig برداشته شد. درعوض، باید هر متغیر را پیکربندی کنید.

• فیلد منسوخ‌شده 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 محلی.

نمونه‌ای از نحوه ارتقا دادن افزونه

        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 برداشته شده است.

دیدن ردیابی‌های پشته غیرنمادین برای برنامه‌های Android در داشبورد Crashlytics

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

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

2. مطمئن شوید که برای اجرای فرمان Firebase CLI crashlytics:symbols:upload آماده هستید تا فایل نماد را تولید و بارگذاری کنید.

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

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

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

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

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

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

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

     هر بار که ساخت نسخه پخش یا هر ساخت دیگری را که می‌خواهید ردیابی‌های پشته نمادین‌شده را در کنسول 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
    //
}

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

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

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

Firebase داده‌ها را به مکان مجموعه داده‌ای که هنگام راه‌اندازی صادر کردن داده به BigQuery انتخاب کرده‌اید صادر می‌کند.

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

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

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

آیا پس‌از ارتقا به زیرساخت برون‌برد جدید برای BigQuery با مشکل مواجه شده‌اید؟

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

همه پروژه‌های Firebase از ۲ مارس ۲۰۲۶ به‌طور خودکار به زیرساخت جدید صادر کردن دسته‌ای ارتقا یافته‌اند.

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

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

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

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

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

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

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

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

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

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

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

اگر نام جدول دسته‌ای قدیمی شما با شناسه دسته نرم‌افزاری یا نام بسته تنظیم‌شده برای «برنامه Firebase» ثبت‌شده شما مطابقت نداشت، یکی از این گزینه‌ها را اجرا کنید تا از اختلالات بیشتر در داده‌های دسته‌ای صادرشده جلوگیری کنید.

آشنایی با نحوه استفاده زیرساخت صادر کردن از شناسه‌ها برای نوشتن داده‌ها در جدول‌های BigQuery

در اینجا نحوه نوشتن داده‌های Crashlytics در جدول‌های دسته‌ای BigQuery توسط دو زیرساخت صادر کردن آورده شده است:

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

• زیرساخت صادر کردن جدید: داده‌ها را در جدولی می‌نویسد که نام آن براساس شناسه بسته نرم‌افزاری یا نام بسته تنظیم‌شده برای «برنامه Firebase» ثبت‌شده شما در پروژه Firebase شما است.

متأسفانه گاهی شناسه دسته نرم‌افزاری یا نام بسته در باینری برنامه شما با شناسه دسته نرم‌افزاری یا نام بسته تنظیم‌شده برای «برنامه Firebase» ثبت‌شده شما در پروژه Firebase مطابقت ندارد. این معمولاً زمانی اتفاق می‌افتد که شخصی شناسه واقعی را درطول ثبت‌نام برنامه وارد نکرده باشد.

اگر این مشکل قبل‌از ارتقا دادن برطرف نشود چه اتفاقی می‌افتد؟

اگر شناسه‌ها در این دو مکان مطابقت نداشته باشند، موارد زیر اتفاق افتاده است:

• اکنون داده‌های Crashlytics شما در جدول دسته‌ای جدیدی BigQuery نوشته می‌شود — یعنی جدول جدیدی با نامی براساس شناسه دسته نرم‌افزاری یا نام بسته تنظیم‌شده برای «برنامه Firebase» ثبت‌شده شما در پروژه Firebase شما.

• هر جدول «قدیمی» موجود با نامی براساس شناسه در دودویی برنامه‌تان دیگر داده‌ای در آن نوشته نمی‌شود.

سناریوهای نمونه از شناسه‌های نامطابق

توجه داشته باشید که نام‌های جدول دسته‌ای BigQuery به‌طور خودکار با _IOS یا _ANDROID اضافه می‌شوند تا پلاتفرم برنامه را نشان دهند.

^{* اگر شناسه در باینری برنامه‌تان با یکی از شناسه‌های تنظیم‌شده برای «برنامه Firebase» مطابقت داشت، زیرساخت صادر کردن جدید جدول جدیدی برای آن شناسه ایجاد نمی‌کرد. درعوض، به نوشتن داده‌های آن برنامه خاص در آن ادامه خواهد داد. همه برنامه‌های دیگر در جدول‌های جدید نوشته خواهند شد.}

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

گزینه‌های کاهش اختلال

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

  1. در کنسول Google Cloud، همه داده‌ها را از جدول قدیمی‌تان در جدول جدیدی که درطول ارتقای زیرساخت ایجاد شده است کپی کنید.

  2. اگر وابستگی‌های پایین‌دستی دارید که به جدول دسته‌ای شما وابسته هستند، آن‌ها را تغییر دهید تا از جدول جدید استفاده کنند.

• گزینه ۲:
  پیکربندی مجدد برای نوشتن دوباره در جدول قدیمی. برای دستیابی به این هدف، باید برخی‌از پیش‌فرض‌ها را در پیکربندی BigQuery لغو کنید.

  1. در کنسول Firebase، «شناسه برنامه Firebase» (برای مثال، 1:1234567890:ios:321abc456def7890) برنامه‌ای را که نام و شناسه جدول دسته‌ای آن عدم تطابق دارد پیدا کنید و یادداشت کنید:
     به settings تنظیمات پروژه بروید، سپس به کارت برنامه‌های شما بروید تا همه «برنامه‌های Firebase» و اطلاعات آن‌ها را ببینید.

  2. در کنسول 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» به‌جای آن در آن بنویسد تغییر دهید (معمولاً این نام جدول قدیمی است که برنامه با زیرساخت صادر کردن قدیمی در آن می‌نوشت).

     6. تغییر پیکربندی را ذخیره کنید.

  3. یک پس‌پر کردن را زمان‌بندی کنید برای روزهایی که جدول قدیمی شما داده‌هایش را ازدست داده است.

  4. پس‌از تکمیل پر کردن داده‌های قبلی، جدول جدید را حذف کنید که به‌طور خودکار توسط زیرساخت صادر کردن جدید ایجاد شده است.