تحديد المشاكل وحلّها في Crashlytics والأسئلة الشائعة بشأنها

ظهور تنسيقات مختلفة (وأحيانًا "خيارات") لبعض المشاكل في جدول المشاكل

قد تلاحظ تنسيقَين مختلفَين للمشاكل المُدرَجة في جدول المشاكل في وحدة تحكّم Firebase. وقد تلاحظ أيضًا ميزة تُسمى "المتغيرات" ضمن بعض المشاكل. إليك السبب:

في أوائل عام 2023، طرحنا محرّك تحليل محسّنًا لتجميع الأحداث، بالإضافة إلى تصميم معدَّل وبعض الميزات المتقدّمة للمشاكل الجديدة (مثل المتغيرات!). يمكنك الاطّلاع على مشاركة المدونة الأخيرة للحصول على جميع التفاصيل، أو قراءة النقاط البارزة أدناه.

تُحلّل Crashlytics جميع الأحداث من تطبيقك (مثل الأعطال والأخطاء غير الفادحة وأخطاء ANR) وتنشئ مجموعات من الأحداث تُسمّى المشاكل، إذ تشترك جميع الأحداث في إحدى المشاكل في نقطة تعذُّر مشتركة.

لتجميع الأحداث في هذه المشاكل، يبحث محرّك التحليل المحسّن الآن في العديد من جوانب الحدث، بما في ذلك اللقطات في تتبُّع تسلسل استدعاء الدوال البرمجية، ورسالة الاستثناء، ورمز الخطأ، وغير ذلك من خصائص النظام الأساسي أو نوع الخطأ.

ومع ذلك، ضمن مجموعة الأحداث هذه، قد تختلف عمليات تتبُّع تسلسل استدعاء الدوال البرمجية التي تؤدي إلى حدوث الخطأ. قد يشير تتبُّع تسلسل استدعاء الدوال البرمجية المختلف إلى سبب جذري مختلف. لتمثيل هذا الاختلاف المحتمل ضمن إحدى المشاكل، ننشئ الآن خيارات ضمن المشاكل، وكل خيار هو مجموعة فرعية من الأحداث في إحدى المشاكل التي تتضمّن نقطة تعذُّر و تتبُّع تسلسل استدعاء الدوال البرمجية مشابهًا. باستخدام المتغيرات، يمكنك تصحيح الأخطاء في تتبُّع تسلسل استدعاء الدوال البرمجية الأكثر شيوعًا ضمن إحدى المشاكل وتحديد ما إذا كانت الأسباب الجذرية المختلفة تؤدي إلى حدوث الخطأ.

في ما يلي التغييرات التي ستلاحظها بعد تطبيق هذه التحسينات:

• تجديد البيانات الوصفية المعروضة ضمن صف المشكلة
  أصبح من الأسهل الآن فهم المشاكل في تطبيقك وتصنيفها.

• عدد أقل من المشاكل المكرّرة
  لا يؤدي تغيير رقم السطر إلى ظهور مشكلة جديدة.

• تسهيل تصحيح الأخطاء المعقّدة التي لها أسباب جذرية مختلفة
  استخدِم الصيغ لتصحيح أخطاء تتبُّع تسلسل استدعاء الدوال البرمجية الأكثر شيوعًا ضمن إحدى المشاكل.

• تنبيهات وإشارات أكثر فائدة
  تمثّل المشكلة الجديدة خطأً جديدًا.

• بحث أكثر فعالية
  يحتوي كل إصدار على المزيد من البيانات الوصفية القابلة للبحث، مثل نوع الاستثناء واسم الحزمة.

إليك طريقة طرح هذه التحسينات:

• عندما نتلقّى أحداثًا جديدة من تطبيقك، سنتحقّق مما إذا كانت تتطابق مع مشكلة حالية.

• في حال عدم العثور على تطابق، سنطبّق تلقائيًا خوارزمية أكثر ذكاءً لتجميع الأحداث، وسننشئ مشكلة جديدة باستخدام تصميم معدَّل للبيانات الوصفية.

هذا هو التعديل الكبير الأول الذي نجريه على تجميع الأحداث. إذا كان لديك ملاحظات أو واجهت أي مشاكل، يُرجى إعلامنا بذلك من خلال تقديم بلاغ.

عدم ظهور سجلّات شريط التنقل

إذا لم تظهر لك سجلّات مسار التنفيذ (iOS+‎ أو Android أو Flutter أو Unity)، ننصحك بالتحقّق من إعدادات تطبيقك بحثًا عن Google Analytics. يُرجى التأكّد من استيفاء المتطلبات التالية:

• لقد فعّلت Google Analytics في مشروعك على Firebase.

• لقد فعّلت مشاركة البيانات في Google Analytics. يمكنك الاطّلاع على مزيد من المعلومات عن هذا الإعداد في مقالة إدارة إعدادات مشاركة البيانات في "إحصاءات Google".

• أضفت إلى تطبيقك حزمة تطوير البرامج (SDK) لمنصة Firebase لنظام التشغيل Google Analytics: iOS+ | Android | Flutter | Unity.
  يجب إضافة حزمة SDK هذه بالإضافة إلى حزمة SDK Crashlytics.

• تستخدِم أحدث إصدارات حزمة تطوير البرامج (SDK) من Firebase لجميع المنتجات التي تستخدمها في تطبيقك (iOS+ | Android | Flutter | Unity).

  بالنسبة إلى تطبيقات Apple وAndroid، احرص بشكل خاص على استخدام الإصدار التالي على الأقل من حزمة تطوير البرامج (SDK) لمنصة Firebase في Google Analytics: iOS+: الإصدار 6.3.1 أو إصدار أحدث (الإصدار 8.9.0 أو إصدار أحدث لنظامَي التشغيل macOS وtvOS) | Android: الإصدار 17.2.3 أو إصدار أحدث (BoM الإصدار 24.7.1 أو إصدار أحدث).

عدم ظهور تنبيهات السرعة

إذا لم تظهر لك تنبيهات السرعة، تأكَّد من أنّك تستخدم

عدم ظهور مقاييس عدم حدوث أعطال (أو ظهور مقاييس غير موثوقة)

إذا لم تظهر لك مقاييس خالية من الأعطال (مثل المستخدمين والجلسات الخالية من الأعطال) أو ظهرت لك مقاييس غير موثوقة، تحقَّق مما يلي:

• تأكَّد من استخدام

• تأكَّد من أنّ إعدادات جمع البيانات لا تؤثّر في جودة مقاييسك الخالية من الأعطال:

  • في حال تفعيل ميزة إعداد التقارير التي تتطلّب موافقة المستخدم من خلال إيقاف ميزة إعداد تقارير الأعطال التلقائي، لا يمكن إرسال معلومات الأعطال إلى Crashlytics إلا من المستخدمين الذين وافقوا صراحةً على جمع البيانات. وبالتالي، ستتأثر دقة مقاييس عدم حدوث أعطال لأنّ Crashlytics لا تتضمّن سوى معلومات الأعطال من هؤلاء المستخدمين الذين وافقوا على مشاركة البيانات (بدلاً من جميع المستخدمين). وهذا يعني أنّ مقاييس "عدم حدوث أعطال" قد تكون أقل موثوقية ولا تعكس الثبات العام لتطبيقك.

  • إذا كانت ميزة جمع البيانات التلقائي غير مفعّلة، يمكنك استخدام sendUnsentReports لإرسال التقارير المخزّنة مؤقتًا على الجهاز إلى Crashlytics. سيؤدي استخدام هذه الطريقة إلى إرسال بيانات الأعطال إلى Crashlytics، ولكن ليس بيانات الجلسات، ما يؤدي إلى عرض الرسوم البيانية في وحدة التحكّم لقيم منخفضة أو صفرية لمقاييس "عدم حدوث أعطال".

كيف يتم احتساب عدد المستخدمين الذين لم يواجهوا أي تعطُّل؟

اطّلِع على فهم مقاييس عدم حدوث الأعطال.

مَن يمكنه الاطّلاع على الملاحظات وكتابتها وحذفها في إحدى المشاكل؟

تتيح الملاحظات لأعضاء المشروع التعليق على مشاكل معيّنة من خلال طرح أسئلة أو تقديم معلومات عن الحالة أو غير ذلك.

عندما ينشر أحد أعضاء المشروع ملاحظة، يتم تصنيفها باستخدام البريد الإلكتروني لحسابه على Google. يظهر عنوان البريد الإلكتروني هذا، بالإضافة إلى الملاحظة، لجميع أعضاء المشروع الذين لديهم إذن بالاطّلاع على الملاحظة.

في ما يلي وصف لأذونات الوصول المطلوبة لعرض الملاحظات وكتابتها وحذفها:

• يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية الاطّلاع على الملاحظات الحالية وحذفها وكتابة ملاحظات جديدة بشأن مشكلة.

  • المالك أو المحرِّر للمشروع، مشرف Firebase، مشرف الجودة، أو مشرف Crashlytics

• يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية الاطّلاع على الملاحظات المنشورة بشأن إحدى المشاكل، ولكن لا يمكنهم حذف ملاحظة أو كتابتها.

  • مُشاهد المشروع أو مُشاهد Firebase أو مُشاهد الجودة أو مُشاهد Crashlytics

ما هي المشكلة التي تراجعت؟

تحدث مشكلة متكررة عندما تكون قد أغلقت المشكلة سابقًا، ولكن Crashlytics يتلقّى تقريرًا جديدًا يفيد بأنّ المشكلة قد تكررت. تعيد Crashlytics تلقائيًا فتح هذه المشاكل التي تم حلّها سابقًا حتى تتمكّن من معالجتها على النحو المناسب لتطبيقك.

في ما يلي مثال على سيناريو يوضّح كيف تصنّف Crashlytics مشكلة على أنّها تراجع:

1. لأول مرة على الإطلاق، يتلقّى Crashlytics تقرير عُطل بشأن Crash "A". يفتح 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 غير المضمّنة يدويًا باتّباع الخطوات التالية:

     • الخيار 1: استخدِم الخيار "السحب والإفلات" المستند إلى وحدة التحكّم في علامة التبويب ملفات dSYM لتحميل أرشيف zip يحتوي على ملفات dSYM الناقصة.
     • الخيار 2: استخدِم برنامج نصي upload-symbols لتحميل ملفات dSYM الناقصة، وذلك لمعرّفات UUID المتوفّرة في علامة التبويب ملفات dSYM.

4. إذا استمر ظهور ملفات dSYM ناقصة أو استمر تعذُّر تحميل الملفات، يُرجى التواصل مع فريق دعم Firebase وتضمين سجلّاتك.

ترميز عمليات تتبُّع تسلسل استدعاء الدوال البرمجية للأعطال رديء

إذا بدا أنّ رموز تتبُّع تسلسل استدعاء الدوال البرمجية غير متطابقة بشكل جيد، تحقَّق مما يلي:

• إذا كانت اللقطات من مكتبة تطبيقك لا تتضمّن مراجع إلى رمز تطبيقك، تأكَّد من عدم ضبط -fomit-frame-pointer كعلامة تجميع.

• إذا ظهرت لك عدّة إطارات (Missing) لمكتبة تطبيقك، تحقَّق مما إذا كانت هناك ملفات dSYM اختيارية مُدرَجة على أنّها مفقودة (لإصدار التطبيق المتأثّر) في علامة التبويب Crashlytics ملفات dSYM في Firebase Console. في حال حدوث ذلك، اتّبِع خطوة تحديد المشاكل وحلّها الواردة في قسم "تنبيه بشأن عدم توفّر ملف dSYM" ضمن الأسئلة الشائعة حول عدم توفّر ملفات dSYM أو عدم تحميلها في هذه الصفحة. يُرجى العِلم أنّ تحميل ملفات dSYM هذه لن يؤدي إلى تحويل الأعطال التي حدثت بالفعل إلى رموز، ولكنّه سيساعد في ضمان تحويل الأعطال المستقبلية إلى رموز.

هل يمكنني استخدام Crashlytics لنظام التشغيل macOS أو tvOS؟

نعم، يمكنك تنفيذ Crashlytics في مشاريع macOS وtvOS. احرص على تضمين الإصدار 8.9.0 أو إصدار أحدث من حزمة Firebase SDK الخاصة بـ Google Analytics لكي تتمكّن الأعطال من الوصول إلى المقاييس التي تجمعها Google Analytics (المستخدمون الذين لم يواجهوا أي أعطال، وأحدث إصدار، وتنبيهات السرعة، وسجلات مسار التنفيذ).

هل يمكنني استخدام Crashlytics في مشروع Firebase يتضمّن عدة تطبيقات على منصات Apple المختلفة؟

يمكنك الآن الإبلاغ عن الأعطال في عدة تطبيقات ضمن مشروع واحد على Firebase، حتى إذا كانت التطبيقات مصمَّمة لمنصات Apple مختلفة (مثل iOS وtvOS وMac Catalyst). في السابق، كان عليك فصل التطبيقات إلى مشاريع Firebase فردية إذا كانت تحتوي على رقم تعريف الحزمة نفسه.

لماذا يتم تسجيل أخطاء ANR على الإصدار 11 من نظام التشغيل Android والإصدارات الأحدث فقط؟

تتيح Crashlytics إمكانية تسجيل أحداث ANR لتطبيقات Android من الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android والإصدارات الأحدث. إنّ واجهة برمجة التطبيقات الأساسية التي نستخدمها لجمع أخطاء ANR (getHistoricalProcessExitReasons) أكثر موثوقية من الأساليب المستندة إلى SIGQUIT أو مراقبة الأداء. لا تتوفّر واجهة برمجة التطبيقات هذه إلا على أجهزة Android 11 والإصدارات الأحدث.

لماذا لا تتضمّن بعض أخطاء ANR أرقام BuildId؟

إذا كانت بعض أخطاء ANR لا تتضمّن BuildId، اتّبِع الخطوات التالية لتحديد المشاكل وحلّها:

• تأكَّد من أنّك تستخدم إصدارًا حديثًا من حزمة تطوير البرامج (SDK) لنظام التشغيل Android Crashlytics والمكوّن الإضافي لنظام Gradle.Crashlytics

  إذا لم تظهر لك أخطاء BuildId في الإصدار 11 من نظام التشغيل Android وبعض أخطاء ANR في الإصدار 12 من نظام التشغيل Android، من المحتمل أنّك تستخدم حزمة تطوير برامج (SDK) أو مكوّنًا إضافيًا لنظام Gradle أو كليهما قديمَين. لجمع BuildId بشكل صحيح لأخطاء ANR هذه، عليك استخدام الإصدارات التالية:

  • ‫Crashlytics Android SDK الإصدار 18.3.5 أو الإصدارات الأحدث (Firebase BoM الإصدار 31.2.2 أو الإصدارات الأحدث)
  • Crashlytics الإصدار 2.9.4 أو الإصدارات الأحدث من المكوّن الإضافي لنظام Gradle

• تحقَّق مما إذا كنت تستخدم موقعًا جغرافيًا غير عادي لمكتباتك المشتركة.

  إذا كانتBuildId فقط هي المفقودة في المكتبات المشتركة لتطبيقك، من المحتمل أنّك لا تستخدم الموقع الجغرافي التلقائي العادي للمكتبات المشتركة. في هذه الحالة، قد لا يتمكّن Crashlytics من تحديد موقع BuildId المرتبط. ننصحك باستخدام الموقع الجغرافي العادي للمكتبات المشتركة.

• تأكَّد من أنّك لا تحذف BuildIds أثناء عملية الإنشاء.

  يُرجى العلم أنّ نصائح تحديد المشاكل وحلّها التالية تنطبق على أخطاء ANR والأعطال الأصلية.

  • تحقَّق مما إذا كانت BuildId موجودة من خلال تنفيذ readelf -n على الملفات الثنائية. إذا لم تكن BuildId متوفّرة، أضِف -Wl,--build-id إلى العلامات لنظام الإنشاء.

  • تأكَّد من أنّك لا تحذف السمة BuildId عن غير قصد في محاولة لتقليل حجم حِزمة APK.

  • إذا كنت تحتفظ بنسختَين من إحدى المكتبات، إحداهما مضغوطة والأخرى غير مضغوطة، احرص على الإشارة إلى النسخة الصحيحة في الرمز.

الاختلافات بين تقارير أخطاء ANR في لوحة بيانات Crashlytics وGoogle Play Console

قد يحدث عدم تطابق بين عدد أخطاء ANR في Google Play وCrashlytics. وهذا أمر متوقّع بسبب الاختلاف في آلية جمع بيانات أخطاء ANR والإبلاغ عنها. تسجّل Crashlytics أخطاء ANR عند بدء تشغيل التطبيق في المرة التالية، بينما ترسل "مؤشرات Android الحيوية" بيانات أخطاء ANR بعد حدوثها.

بالإضافة إلى ذلك، لا تعرض Crashlytics إلا أخطاء ANR التي تحدث على الأجهزة التي تعمل بالإصدار 11 من نظام التشغيل Android أو الإصدارات الأحدث، مقارنةً بـ Google Play الذي يعرض أخطاء ANR من الأجهزة التي تتضمّن "خدمات Google Play" وتم قبول الموافقة على جمع البيانات.

لماذا تظهر الأعطال من ملفات .kt على أنّها مشاكل .java؟

عندما يستخدم تطبيق أداة تشويش لا تعرض امتداد الملف، تنشئ Crashlytics كل مشكلة باستخدام امتداد الملف .java تلقائيًا.

لكي يتمكّن Crashlytics من إنشاء مشاكل باستخدام امتداد الملف الصحيح، تأكَّد من أنّ تطبيقك يستخدم الإعداد التالي:

• يستخدم الإصدار 4.2.0 من المكوّن الإضافي لنظام Gradle المتوافق مع Android أو إصدارًا أحدث
• يستخدم R8 مع تفعيل التشويش. لتحديث تطبيقك إلى R8، يُرجى الرجوع إلى هذه المستندات.

يُرجى العِلم أنّه بعد التحديث إلى الإعداد الموضّح أعلاه، قد تبدأ في رؤية مشاكل .kt جديدة هي نسخ مكرّرة من مشاكل .java حالية. يمكنك الاطّلاع على الأسئلة الشائعة لمعرفة المزيد حول هذه الحالة.

لماذا تظهر لي مشاكل .kt مكرّرة من مشاكل .java حالية؟

اعتبارًا من منتصف كانون الأول (ديسمبر) 2021، Crashlyticsأصبحنا نوفّر دعمًا محسّنًا للتطبيقات التي تستخدم لغة Kotlin.

حتى وقت قريب، لم تكن أدوات التشويش المتاحة تعرض امتداد الملف، لذا كانت Crashlytics تنشئ كل مشكلة باستخدام امتداد الملف .java تلقائيًا. ومع ذلك، بدءًا من الإصدار 4.2.0 من Android Gradle، يتيح R8 استخدام امتدادات الملفات.

من خلال هذا التحديث، يمكن الآن لأداة Crashlytics تحديد ما إذا كان كل صف مستخدَم في التطبيق مكتوبًا بلغة Kotlin، وتضمين اسم الملف الصحيح في توقيع المشكلة. يتم الآن تحديد مصدر الأعطال بشكل صحيح على أنّه ملف .kt (حسب الاقتضاء) إذا كان تطبيقك يتضمّن الإعداد التالي:

• يستخدم تطبيقك الإصدار 4.2.0 من Android Gradle أو إصدارًا أحدث.
• يستخدم تطبيقك أداة R8 مع تفعيل ميزة التشويش.

بما أنّ الأعطال الجديدة تتضمّن الآن امتداد الملف الصحيح في تواقيع المشاكل، قد تظهر لك مشاكل جديدة تحمل التصنيف .kt، وهي في الواقع مجرّد نُسخ مكرّرة من المشاكل الحالية التي تحمل التصنيف .java. في وحدة تحكّم Firebase، نحاول تحديد ما إذا كانت مشكلة .kt جديدة هي نسخة مكرّرة محتملة من مشكلة حالية تحمل التصنيف .java، وإبلاغك بذلك.

عدم حدوث أعطال عند استخدام Dexguard

إذا ظهر لك الاستثناء التالي، من المحتمل أنّك تستخدم إصدارًا من DexGuard غير متوافق مع حزمة تطوير البرامج (SDK) Firebase Crashlytics:

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

لا يؤدي هذا الاستثناء إلى تعطُّل تطبيقك، ولكنّه يمنعه من إرسال تقارير الأعطال. لحلّ هذه المشكلة، اتّبِع الخطوات التالية:

1. تأكَّد من استخدام أحدث إصدار من DexGuard 8.x. يحتوي الإصدار الأخير على قواعد تتطلّبها حزمة تطوير البرامج (SDK) الخاصة بـ "Firebase Crashlytics".

2. إذا كنت لا تريد تغيير إصدار DexGuard، حاوِل إضافة السطر التالي إلى قواعد التشويش (في ملف إعداد DexGuard):

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

كيف يمكن الترقية إلى Crashlytics الإصدار 3 من المكوّن الإضافي لنظام Gradle؟

أحدث إصدار من Crashlytics المكوّن الإضافي لنظام Gradle هو إصدار رئيسي (الإصدار 3.0.0) ويتم تحديث حزمة تطوير البرامج (SDK) من خلال إيقاف التوافق مع الإصدارات الأقدم من Gradle والمكوّن الإضافي لنظام Gradle المتوافق مع Android. بالإضافة إلى ذلك، تعمل التغييرات في هذا الإصدار على حلّ المشاكل المتعلّقة بالإصدار 8.1 والإصدارات الأحدث من المكوّن الإضافي لنظام Gradle في Android، كما تعمل على تحسين التوافق مع التطبيقات الأصلية وعمليات الإنشاء المخصّصة.

الحد الأدنى من المتطلبات

يجب استيفاء الحد الأدنى من المتطلبات التالية لاستخدام Crashlytics الإصدار 3 من المكوّن الإضافي لنظام Gradle:

• الإصدار 8.1 من المكوّن الإضافي لنظام Gradle المتوافق مع Android والإصدارات الأحدث
  يمكنك ترقية هذا المكوّن الإضافي باستخدام مساعد ترقية المكوّن الإضافي لنظام Gradle المتوافق مع Android في أحدث إصدار من "استوديو Android".

• google-servicesالمكوّن الإضافي لنظام Gradle في Firebase‏ 4.4.1 أو الإصدارات الأحدث
  يمكنك ترقية هذا المكوّن الإضافي من خلال تحديد أحدث إصدار في ملف إنشاء Gradle الخاص بمشروعك، كما يلي:

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"

في الإصدار 3 من المكوّن الإضافي 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.

• تم استبدال حقل الإغلاق 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 بإحدى الطريقتين التاليتين:

• الخيار 1: تحديد المسار من خلال إضافة firebaseCrashlytics في ملف build.gradle

  أضِف ما يلي إلى ملف build.gradle.kts على مستوى التطبيق:

  الإصدار 3.0.0 أو الإصدارات الأحدث من المكوّن الإضافي لنظام Gradle

  android {
    buildTypes {
      release {
        configure<CrashlyticsExtension> {
          nativeSymbolUploadEnabled = true
          // Add these optional fields to specify the path to the executable
          symbolGeneratorType = "breakpad"
          breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
        }
      }
    }
  }

  إصدارات المكوّن الإضافي الأقدم

  android {
    // ...
    buildTypes {
      // ...
      release {
        // ...
        firebaseCrashlytics {
          // existing; required for either symbol file generator
          nativeSymbolUploadEnabled true
          // Add this optional new block to specify the path to the executable
          symbolGenerator {
            breakpad {
              binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
     }
  }

• الخيار 2: تحديد المسار من خلال سطر سمة في ملف Gradle properties

  يمكنك استخدام السمة com.google.firebase.crashlytics.breakpadBinary لتحديد مسار الملف التنفيذي.

  يمكنك تعديل ملف خصائص Gradle يدويًا أو تعديل الملف من خلال سطر الأوامر. على سبيل المثال، لتحديد المسار من خلال سطر الأوامر، استخدِم أمرًا مثل ما يلي:

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

هل تتوافق Crashlytics مع armeabi؟

لا تتوافق حزمة تطوير البرامج (NDK) في Firebase Crashlytics مع ARMv5 (armeabi). تمت إزالة دعم واجهة ABI هذه اعتبارًا من الإصدار 17 من حزمة NDK.

ظهور تتبُّعات تسلسل استدعاء الدوال البرمجية غير المحوَّلة إلى رموز في لوحة بيانات Crashlytics لتطبيقات Android

إذا كنت تستخدم Unity IL2CPP وتظهر لك عمليات تتبُّع تسلسل استدعاء الدوال البرمجية غير مرتبطة برموز، جرِّب ما يلي:

1. تأكَّد من استخدام الإصدار 8.6.1 أو إصدار أحدث من حزمة تطوير البرامج (SDK) Crashlytics Unity.

2. تأكَّد من إعداد وتنفيذ الأمر Firebase CLI crashlytics:symbols:upload لإنشاء ملف الرموز وتحميله.

   يجب تنفيذ أمر واجهة سطر الأوامر هذا في كل مرة تنشئ فيها إصدارًا أو أي إصدار تريد عرض عمليات تتبُّع تسلسل استدعاء الدوال البرمجية مع رموز في وحدة تحكّم Firebase. يمكنك الاطّلاع على مزيد من المعلومات في مقالة الحصول على تقارير أعطال قابلة للقراءة.

هل يمكن استخدام Crashlytics مع التطبيقات التي تستخدم IL2CPP؟

نعم، يمكن لـ Crashlytics عرض عمليات تتبُّع تسلسل استدعاء الدوال البرمجية التي تم تحويلها إلى رموز لتطبيقاتك التي تستخدم IL2CPP. تتوفّر هذه الإمكانية للتطبيقات التي تم إصدارها على نظام التشغيل Android أو منصات Apple. في ما يلي الخطوات التي يجب اتّخاذها:

1. تأكَّد من استخدام الإصدار 8.6.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) الخاصة بـ Crashlytics Unity.

2. أكمِل المهام اللازمة لمنصتك:

   • بالنسبة إلى تطبيقات منصة Apple: ليس عليك اتّخاذ أي إجراءات خاصة. بالنسبة إلى تطبيقات منصة Apple، يضبط المكوّن الإضافي Firebase Unity Editor مشروع Xcode تلقائيًا لتحميل الرموز.

   • بالنسبة إلى تطبيقات Android: تأكَّد من إعدادك وتنفيذك لأمر Firebase CLI crashlytics:symbols:upload لإنشاء ملف الرموز وتحميله.

     يجب تنفيذ أمر واجهة سطر الأوامر هذا في كل مرة تنشئ فيها إصدارًا أو أي إصدار تريد عرض عمليات تتبُّع تسلسل استدعاء الدوال البرمجية مع رموز في وحدة تحكّم Firebase. يمكنك الاطّلاع على مزيد من المعلومات في مقالة الحصول على تقارير أعطال قابلة للقراءة.

لماذا يجب أن يبلغ التطبيق عن الاستثناءات غير المعالَجة على أنّها أخطاء فادحة؟

من خلال الإبلاغ عن الاستثناءات غير المعالَجة على أنّها أخطاء فادحة، يمكنك الحصول على مؤشر أكثر واقعية للاستثناءات التي قد تؤدي إلى عدم إمكانية تشغيل اللعبة، حتى إذا استمر التطبيق في العمل.

يُرجى العِلم أنّه في حال بدأت في تسجيل الأخطاء الفادحة، من المحتمل أن تنخفض النسبة المئوية للمستخدمين الذين لم يواجهوا أي أعطال، ولكن سيكون مقياس المستخدمين الذين لم يواجهوا أي أعطال أكثر تعبيرًا عن تجارب المستخدمين النهائيين مع تطبيقك.

ما هي الاستثناءات التي سيتم الإبلاغ عنها كأخطاء فادحة؟

لكي يتمكّن Crashlytics من تسجيل استثناء لم يتم رصده على أنّه خطأ فادح، يجب استيفاء الشرطين التاليين:

• أثناء عملية الإعداد في تطبيقك، يجب ضبط قيمة السمة ReportUncaughtExceptionsAsFatal على true.

• يُطلق تطبيقك (أو إحدى المكتبات المُضمَّنة) استثناءً لم يتم رصده. لا يُعدّ الاستثناء الذي تم إنشاؤه ولم يتم طرحه استثناءً لم يتم رصده.

بعد تفعيل إعداد التقارير عن الاستثناءات غير المعالَجة كأخطاء فادحة، أصبح لديّ الآن العديد من الأخطاء الفادحة الجديدة. كيف يمكنني التعامل مع هذه الاستثناءات بشكل صحيح؟

عندما تبدأ في تلقّي تقارير عن الأخطاء غير المعالَجة باعتبارها أخطاء فادحة، إليك بعض الخيارات للتعامل مع هذه الأخطاء غير المعالَجة:

• فكِّر في كيفية بدء رصد هذه الاستثناءات غير المعالَجة والتعامل معها.
• ننصحك بالنظر في خيارات مختلفة لتسجيل الاستثناءات في وحدة تصحيح الأخطاء في Unity وفي Crashlytics.

التقاط الاستثناءات التي تم طرحها والتعامل معها

يتم إنشاء الاستثناءات وطرحها للإشارة إلى الحالات غير المتوقعة أو الاستثنائية. يتضمّن حلّ المشاكل التي يوضّحها الاستثناء الذي تم طرحه إعادة البرنامج إلى حالة معروفة (وهي عملية تُعرف باسم معالجة الاستثناء).

من أفضل الممارسات رصد جميع الاستثناءات المتوقّعة والتعامل معها، ما لم يتعذّر إعادة البرنامج إلى حالة معروفة.

للتحكّم في أنواع الاستثناءات التي يتم رصدها ومعالجتها بواسطة الرمز البرمجي، ضَع الرمز البرمجي الذي قد يؤدي إلى إنشاء استثناء في كتلة try-catch. احرص على أن تكون الشروط في عبارات catch بأضيق نطاق ممكن للتعامل مع الاستثناءات المحدّدة بشكل مناسب.

تسجيل الاستثناءات في Unity أو Crashlytics

تتوفّر عدة طرق لتسجيل الاستثناءات في Unity أو Crashlytics للمساعدة في تحديد المشكلة وحلّها.

عند استخدام Crashlytics، إليك الخياران الأكثر شيوعًا والموصى بهما:

• الخيار 1: الطباعة في وحدة تحكّم Unity، ولكن بدون إرسال تقارير إلى Crashlytics أثناء التطوير أو تحديد المشاكل وحلّها

  • يمكنك الطباعة إلى وحدة تحكّم Unity باستخدام Debug.Log(exception) وDebug.LogWarning(exception) وDebug.LogError(exception)، التي تطبع محتويات الاستثناء إلى وحدة تحكّم Unity ولا تعيد طرح الاستثناء.

• الخيار 2: التحميل إلى Crashlytics لإعداد تقارير موحّدة في لوحة بيانات Crashlytics في الحالات التالية:

  • إذا كان الاستثناء يستحق التسجيل لتصحيح خطأ محتمل في حدث لاحق، استخدِم Crashlytics.Log(exception.ToString()).Crashlytics
  • إذا كان يجب مواصلة إرسال تقرير عن استثناء إلى Crashlytics على الرغم من رصده ومعالجته، استخدِم Crashlytics.LogException(exception) لتسجيله كحدث غير قاتل.

ومع ذلك، إذا أردت الإبلاغ يدويًا عن حدث خطير إلى Unity Cloud Diagnostics، يمكنك استخدام Debug.LogException. يطبع هذا الخيار الاستثناء في وحدة تحكّم Unity مثل الخيار 1، ولكنّه يطرح الاستثناء أيضًا (سواء تم طرحه أو رصده بعد). ويتم عرض الخطأ بشكل غير محلي. وهذا يعني أنّه حتى إذا كان هناك Debug.LogException(exception) يحتوي على كتل try-catch، سيظل يؤدي إلى حدوث استثناء لم يتم رصده.

لذلك، استخدِم الدالة Debug.LogException فقط إذا كنت تريد تنفيذ كل مما يلي:

• لطباعة الاستثناء في وحدة تحكّم Unity.
• لتحميل الاستثناء إلى Crashlytics كحدث فادح.
• لإظهار الاستثناء، يجب التعامل معه على أنّه استثناء غير مرصود، ويجب إرساله إلى Unity Cloud Diagnostics.

يُرجى العِلم أنّه إذا كنت تريد طباعة استثناء تم رصده في وحدة تحكّم Unity و تحميله إلى Crashlytics كحدث غير مميت، عليك اتّباع الخطوات التالية بدلاً من ذلك:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}

يستخدم التطبيق أيضًا حزمة تطوير البرامج (SDK) الخاصة بـ "Google Mobile Ads"، ولكن لا تحدث أعطال

إذا كان مشروعك يستخدم Crashlytics إلى جانب حزمة SDK الخاصة بـ Google Mobile Ads، من المحتمل أن تتداخل أدوات تسجيل الأعطال عند تسجيل معالجات الاستثناءات. لحلّ المشكلة، أوقِف ميزة "إعداد تقارير الأعطال" في حزمة تطوير البرامج (SDK) الخاصة بـ Mobile Ads من خلال استدعاء disableSDKCrashReporting.

أين تقع مجموعة بيانات BigQuery؟

تصدِّر Firebase البيانات إلى الموقع الجغرافي لمجموعة البيانات الذي اخترته عند إعداد عملية تصدير البيانات إلى BigQuery.

• ينطبق هذا الموقع الجغرافي على مجموعة بيانات Crashlytics ومجموعة بيانات جلسات Firebase (في حال تفعيل ميزة تصدير بيانات الجلسات).

• ينطبق هذا الموقع الجغرافي فقط على البيانات التي يتم تصديرها إلى BigQuery، ولا يؤثّر في الموقع الجغرافي للبيانات المخزَّنة لاستخدامها في لوحة بيانات Crashlytics في وحدة تحكّم Firebase أو في Android Studio.

• بعد إنشاء مجموعة بيانات، لا يمكن تغيير موقعها الجغرافي، ولكن يمكنك نسخها إلى موقع جغرافي آخر أو نقلها (إعادة إنشائها) يدويًا في موقع جغرافي آخر. لمزيد من المعلومات، اطّلِع على مقالة تغيير الموقع الجغرافي لعمليات التصدير الحالية.

كيف يمكن الترقية إلى بنية التصدير الأساسية الجديدة في BigQuery؟

في منتصف تشرين الأول (أكتوبر) 2024، أطلقت Crashlytics بنية أساسية جديدة لتصدير البيانات المجمّعة من Crashlytics إلى BigQuery.

• إذا فعّلت ميزة التصدير المجمّع بعد أكتوبر 2024، سيستخدم مشروعك على Firebase تلقائيًا البنية الأساسية الجديدة للتصدير. ليس عليك اتّخاذ أي إجراء.

• إذا فعّلت ميزة التصدير المجمّع قبل أكتوبر 2024 أو خلاله، راجِع المعلومات الواردة في الأسئلة الشائعة هذه لتحديد ما إذا كان عليك اتّخاذ أي إجراء.

ستتم تلقائيًا ترقية جميع مشاريع Firebase إلى البنية الأساسية الجديدة لتصدير البيانات المجمّعة في أقرب وقت ممكن في 9 يناير 2026. يمكنك الترقية قبل هذا التاريخ، ولكن تأكَّد من أنّ جداول الدفعة BigQuery تستوفي المتطلبات الأساسية للترقية.

يمكنك الترقية إلى البنية الأساسية الجديدة، ولكن تأكَّد من أنّ جداول الدفعات في BigQuery تستوفي المتطلبات الأساسية للترقية.

تحديد ما إذا كنت تستخدم البنية الأساسية الجديدة

إذا فعّلت ميزة التصدير المجمّع في منتصف أكتوبر 2024 أو بعده، سيستخدم مشروعك على Firebase تلقائيًا البنية الأساسية الجديدة للتصدير.

يمكنك التحقّق من البنية الأساسية التي يستخدمها مشروعك: انتقِل إلى وحدة تحكّم Google Cloud، وإذا كان "إعداد نقل البيانات" يحمل التصنيف Firebase Crashlytics with Multi-Region Support، يعني ذلك أنّ مشروعك يستخدم بنية التصدير الأساسية الجديدة.

الاختلافات المهمة بين البنية الأساسية القديمة للتصدير والبنية الأساسية الجديدة للتصدير

• تتيح البنية الأساسية الجديدة تحديد مواقع جغرافية لمجموعات البيانات خارج الولايات المتحدة.Crashlytics

  • تم تفعيل التصدير قبل منتصف أكتوبر 2024 و تمت ترقيته إلى البنية الأساسية الجديدة للتصدير: يمكنك الآن تغيير الموقع الجغرافي لتصدير البيانات بشكل اختياري.

  • تم تفعيل التصدير في منتصف أكتوبر 2024 أو بعد ذلك: طُلب منك أثناء عملية الإعداد اختيار موقع جغرافي لتصدير البيانات.

• لا تتيح البنية الأساسية الجديدة إعادة ملء البيانات من قبل تفعيل التصدير.

  • كانت البنية الأساسية القديمة تتيح تعبئة البيانات السابقة لمدة تصل إلى 30 يومًا قبل تاريخ تفعيل ميزة التصدير.

  • تتيح البنية الأساسية الجديدة عمليات إعادة تعبئة تصل إلى آخر 30 يومًا أو لأحدث تاريخ فعّلت فيه التصدير إلى BigQuery (أيهما أحدث).

• تسمّي البنية الأساسية الجديدة جداول الدفعات باستخدام المعرّفات التي تم ضبطها لتطبيقاتك على Firebase في مشروعك على Firebase.BigQuery

  • كانت البنية الأساسية القديمة تكتب البيانات في جداول مجمّعة بأسماء تستند إلى أرقام تعريف الحِزم أو أسماء الحِزم في الرمز الثنائي لتطبيقك.

  • تكتب البنية الأساسية الجديدة البيانات في جداول مجمّعة بأسماء تستند إلى أرقام تعريف الحِزم أو أسماء الحِزم المحدّدة لتطبيقات Firebase المسجّلة في مشروعك على Firebase.

الخطوة 1: المتطلبات الأساسية للترقية

1. تأكَّد من أنّ جداول الدفعات BigQuery الحالية تستخدم معرّفات مطابقة لمعرّفات الحِزم أو أسماء الحِزم المحدّدة لتطبيقات Firebase المسجّلة في مشروعك على Firebase. في حال عدم تطابقها، قد تواجه انقطاعات في بيانات الدُفعات التي تم تصديرها. ستكون معظم المشاريع في حالة مناسبة ومتوافقة، ولكن من المهم التحقّق من ذلك قبل الترقية.

   • يمكنك العثور على جميع تطبيقات Firebase المسجّلة في مشروعك على Firebase في Firebase Console: انتقِل إلى settings إعدادات المشروع، ثم انتقِل إلى بطاقة تطبيقاتك للاطّلاع على جميع تطبيقات Firebase ومعلوماتها.

   • يمكنك العثور على جميع جداول الدفعات في BigQuery ضمن صفحة BigQuery في وحدة تحكّم Google Cloud.

   على سبيل المثال، إليك الحالات المثالية التي لن تواجه فيها أي مشاكل عند الترقية:

   • لديك جدول دفعات باسم com_yourcompany_yourproject_IOS وتطبيق Firebase iOS+ بمعرّف الحزمة com.yourcompany.yourproject مسجَّل في مشروعك على Firebase.

   • لديك جدول دفعي باسم com_yourcompany_yourproject_ANDROID وتطبيق Android على Firebase باسم الحزمة com.yourcompany.yourproject مسجَّل في مشروعك على Firebase.

2. إذا كانت لديك أسماء جداول دفعية لا تتطابق مع المعرّفات التي تم ضبطها لتطبيقاتك المسجّلة على Firebase، عليك اتّباع التعليمات الواردة لاحقًا في هذه الصفحة قبل الترقية يدويًا أو قبل 9 يناير 2026 لتجنُّب حدوث انقطاع في عملية التصدير الدفعي.

الخطوة 2: الترقية يدويًا إلى البنية الأساسية الجديدة

إذا فعّلت ميزة التصدير المجمّع قبل منتصف أكتوبر 2024، يمكنك الترقية يدويًا إلى البنية الأساسية الجديدة ببساطة عن طريق إيقاف ميزة تصدير بيانات Crashlytics ثم إعادة تفعيلها في وحدة تحكّم Firebase.

في ما يلي الخطوات المفصّلة التي يجب اتّباعها:

1. في وحدة تحكّم Firebase، انتقِل إلى صفحة عمليات الدمج.

2. في بطاقة BigQuery، انقر على إدارة.

3. انقر على شريط التمرير Crashlytics لإيقاف خيار التصدير. عندما يُطلب منك ذلك، أكِّد رغبتك في إيقاف عملية تصدير البيانات.

4. أعِد تفعيل شريط التمرير Crashlytics على الفور لإعادة تفعيل التصدير. عندما يُطلب منك ذلك، أكِّد أنّك تريد تصدير البيانات.

   تتم الآن عملية تصدير بيانات Crashlytics إلى BigQuery باستخدام البنية الأساسية الجديدة للتصدير.

لا يتطابق اسم جدول الدفعات الحالي مع معرّف تطبيق Firebase