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

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

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

في هذه الصفحة، يمكنك العثور على معلومات حول أنواع المواضيع التالية:

تحديد المشاكل العامة وحلّها، بما في ذلك الأسئلة حول عرض البيانات أو التعامل مع البيانات في وحدة تحكّم Firebase والأسئلة حول المشاكل التي تم حلّها ثم عادت للظهور.
الدعم الخاص بالمنصات، بما في ذلك الأسئلة الخاصة بمنصات Apple وAndroid وUnity
الدعم بشأن عمليات الدمج، بما في ذلك الأسئلة حول BigQuery

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

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

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

في أوائل عام 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 مشكلة على أنّها تراجع:

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

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

لماذا تظهر لي مشاكل متكرّرة في الإصدارات القديمة من التطبيق؟

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

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

إذا كنت لا تريد إعادة فتح مشكلة بسبب خوارزمية التراجع، يمكنك "كتم" المشكلة بدلاً من إغلاقها.

الدعم الخاص بكل منصة

توفّر الأقسام التالية الدعم لتحديد المشاكل وحلّها على مستوى النظام الأساسي والأسئلة الشائعة: iOS+ | Android | Unity.

التوافق مع منصات Apple

ملفات dSYM غير متوفّرة أو لا يتم تحميلها

لتحميل ملفات dSYM الخاصة بمشروعك والحصول على ناتج تفصيلي، تحقَّق مما يلي:

تأكَّد من أنّ مرحلة إنشاء مشروعك تتضمّن Crashlytics run script، ما يتيح لـ Xcode تحميل ملفات dSYM الخاصة بمشروعك في مدّة التصميم (يمكنك الاطّلاع على بدء Crashlytics للحصول على تعليمات حول إضافة النص البرمجي). بعد تعديل مشروعك، أجبِر التطبيق على تعطُّل وتأكَّد من ظهور العطل في لوحة بيانات Crashlytics.
إذا ظهر لك تنبيه "ملف dSYM غير متوفّر" في وحدة تحكّم Firebase، راجِع Xcode للتأكّد من أنّه ينتج ملفات dSYM بشكلٍ سليم للإصدار.
إذا كان Xcode ينتج ملفات dSYM بشكل صحيح، ولكن استمر ظهور رسالة تفيد بأنّ ملفات dSYM غير متوفّرة، من المحتمل أنّ أداة البرنامج النصي للتنفيذ معلّقة أثناء تحميل ملفات dSYM. في هذه الحالة، جرِّب كلّاً مما يلي:
- تأكَّد من استخدام أحدث إصدار من Crashlytics.
- حمِّل ملفات dSYM الناقصة يدويًا باتّباع الخطوات التالية:
  - الخيار 1: استخدِم الخيار "السحب والإفلات" المستند إلى وحدة التحكّم في علامة التبويب ملفات dSYM لتحميل أرشيف مضغوط يحتوي على ملفات dSYM الناقصة.
  - الخيار 2: استخدِم نص upload-symbols البرمجي لتحميل ملفات dSYM غير المضمّنة، وذلك لمعرّفات UUID المقدَّمة في علامة التبويب ملفات dSYM.
إذا استمر ظهور ملفات dSYM غير متوفّرة أو استمر تعذُّر تحميل الملفات، يُرجى التواصل مع فريق دعم Firebase مع تضمين السجلات.

ترميز الأعطال غير صحيح

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

إذا كانت اللقطات من مكتبة تطبيقك لا تتضمّن مراجع إلى رمز تطبيقك، تأكَّد من عدم ضبط -fomit-frame-pointer كعلامة تجميع.
إذا ظهرت لك عدّة إطارات (Missing) لمكتبة تطبيقك، تحقّق مما إذا كانت هناك ملفات dSYM اختيارية مُدرَجة على أنّها غير متوفّرة (لإصدار التطبيق المتأثّر) في علامة التبويب Crashlytics ملفات dSYM في وحدة تحكّم Firebase. إذا كان الأمر كذلك، اتّبِع خطوة تحديد المشاكل وحلّها الواردة في قسم "تنبيه بشأن عدم توفّر ملف 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 إذا كانت تحتوي على رقم تعريف الحزمة نفسه.

التوافق مع Android

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

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

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

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

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

إذا لم تظهر لك BuildIds لنظام التشغيل Android 11 وبعض أخطاء ANR في Android 12، من المحتمل أنّك تستخدم حزمة تطوير برامج (SDK) أو مكوّنًا إضافيًا لنظام Gradle أو كليهما قديمَين. لجمع BuildIds بشكل صحيح لأخطاء ANR هذه، عليك استخدام الإصدارات التالية:
- Crashlytics الإصدار 18.3.5 من حزمة تطوير البرامج (SDK) على Android أو إصدار أحدث (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 من المكوّن الإضافي لنظام Gradle المتوافق مع Android، يتيح R8 استخدام امتدادات الملفات.

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

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

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

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

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

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

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

تأكَّد من استخدام أحدث إصدار من DexGuard 8.x. يحتوي أحدث إصدار على قواعد تتطلّبها حزمة تطوير البرامج (SDK) الخاصة بـ "Firebase Crashlytics".
إذا كنت لا تريد تغيير إصدار DexGuard، حاوِل إضافة السطر التالي إلى قواعد التشويش (في ملف إعداد DexGuard):
```
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
```

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

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

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

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

الإصدار 8.1 من المكوّن الإضافي لنظام Gradle المتوافق مع Android أو إصدار أحدث
يمكنك ترقية هذا المكوّن الإضافي باستخدام مساعِد ترقية المكوّن الإضافي لنظام Gradle المتوافق مع Android في أحدث إصدار من "استوديو Android".
الإصدار 4.4.1 أو إصدار أحدث من المكوّن الإضافي google-services لنظام Gradle في Firebase
يمكنك ترقية هذا المكوّن الإضافي من خلال تحديد أحدث إصدار في ملف Gradle الخاص بمشروعك، كما يلي:

Kotlin

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

Groovy

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

تغييرات على الإضافة "Crashlytics"

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

مثال على كيفية ترقية الإضافة

Kotlin

قبل

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

الميزات الجديدة في الإصدار 3

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

Groovy

قبل

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

الميزات الجديدة في الإصدار 3

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

الدعم الخاص بـ Android NDK

الاختلافات بين تتبُّع تسلسل استدعاء الدوال البرمجية في 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

يمكنك استخدام السمة 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.

دعم Unity

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

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

تأكَّد من استخدام الإصدار 8.6.1 أو إصدار أحدث من حزمة تطوير البرامج (SDK) الخاصة بـ Crashlytics Unity.
تأكَّد من إعداد وتنفيذ الأمر Firebase CLI crashlytics:symbols:upload لإنشاء ملف الرموز وتحميله.

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

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

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

تأكَّد من استخدام الإصدار 8.6.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) الخاصة بـ Crashlytics Unity.
أكمِل المهام اللازمة لمنصتك:
- بالنسبة إلى التطبيقات على منصة Apple: ليس عليك اتّخاذ أي إجراءات خاصة. بالنسبة إلى تطبيقات منصة Apple، يضبط المكوّن الإضافي Firebase Unity Editor تلقائيًا مشروع Xcode لتحميل الرموز.
- بالنسبة إلى تطبيقات Android: تأكَّد من إعدادك وتنفيذك للأمر crashlytics:symbols:upload في واجهة سطر الأوامر Firebase لإنشاء ملف الرموز وتحميله.
  
  يجب تنفيذ أمر واجهة سطر الأوامر هذا في كل مرة تنشئ فيها إصدارًا أو أي إصدار تريد عرض عمليات تتبُّع تسلسل استدعاء الدوال البرمجية مع رموز في وحدة تحكّم Firebase. يمكنك الاطّلاع على مزيد من المعلومات في مقالة الحصول على تقارير أعطال قابلة للقراءة.

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

يمكن لـ Crashlytics الإبلاغ عن الاستثناءات غير المعالَجة كأخطاء فادحة (بدءًا من الإصدار 10.4.0 من حزمة تطوير البرامج (SDK) في Unity). تساعد الأسئلة الشائعة التالية في توضيح الأساس المنطقي وأفضل الممارسات لاستخدام هذه الميزة.

لماذا يجب أن يبلغ التطبيق عن الاستثناءات غير المعالَجة كأخطاء خطيرة؟

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

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

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

لكي يتمكّن 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 لاحق، استخدِم Crashlytics.Log(exception.ToString()).
- إذا كان يجب مواصلة إرسال تقرير عن استثناء إلى 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.
بعد إنشاء مجموعة بيانات، لا يمكن تغيير موقعها الجغرافي، ولكن يمكنك نسخها إلى موقع جغرافي آخر أو نقلها (إعادة إنشائها) يدويًا في موقع جغرافي آخر. لمزيد من المعلومات، اطّلِع على مقالة تغيير الموقع الجغرافي لعمليات التصدير الحالية.

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

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

تمت ترقية جميع مشاريع Firebase تلقائيًا إلى البنية الأساسية الجديدة لتصدير البيانات المجمّعة اعتبارًا من 2 مارس 2026.

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

تتيح البنية الأساسية الجديدة استخدام مواقع مجموعات البيانات Crashlytics خارج الولايات المتحدة.
- تم تفعيل التصدير قبل منتصف أكتوبر 2024 وتمت ترقيته إلى البنية الأساسية الجديدة للتصدير: يمكنك الآن تغيير الموقع الجغرافي لتصدير البيانات بشكل اختياري.
- تم تفعيل ميزة التصدير في منتصف أكتوبر 2024 أو بعد ذلك: طُلب منك أثناء عملية الإعداد اختيار موقع جغرافي لتصدير البيانات.
لا تتيح البنية الأساسية الجديدة إعادة ملء البيانات من قبل تفعيل ميزة التصدير.
- كانت البنية الأساسية القديمة تتيح تعبئة البيانات السابقة لمدة تصل إلى 30 يومًا قبل تاريخ تفعيل ميزة التصدير.
- تتيح البنية الأساسية الجديدة عمليات إعادة تعبئة تصل إلى آخر 30 يومًا أو لأحدث تاريخ فعّلت فيه ميزة التصدير إلى BigQuery (أيهما أحدث).
تسمّي البنية الأساسية الجديدة BigQuery جداول الدفعات باستخدام المعرّفات التي تم ضبطها لتطبيقات Firebase في مشروع Firebase.
- كانت البنية الأساسية القديمة تكتب البيانات في جداول مجمّعة بأسماء تستند إلى أرقام تعريف الحِزم أو أسماء الحِزم في الرمز الثنائي لتطبيقك.
- تكتب البنية الأساسية الجديدة البيانات في جداول مجمّعة بأسماء تستند إلى أرقام تعريف الحِزم أو أسماء الحِزم المحدّدة لتطبيقات Firebase المسجّلة في مشروع Firebase.

إذا لم يتطابق اسم جدول الدفعات القديم مع معرّف تطبيقك على Firebase

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

التعرّف على كيفية استخدام البنية الأساسية للتصدير المعرّفات لكتابة البيانات في جداول BigQuery

في ما يلي كيفية كتابة بنيتَي التصدير لبيانات Crashlytics في جداول الدفعات BigQuery:

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

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

ماذا يحدث إذا لم يتم إصلاح هذه المشكلة قبل الترقية؟

إذا لم تتطابق المعرّفات في هذين الموقعَين، يعني ذلك حدوث ما يلي:

تتم الآن كتابة بيانات Crashlytics في جدول دفعي جديد BigQuery، أي جدول جديد باسم يستند إلى معرِّف الحزمة أو اسم الحزمة المحدّد لتطبيق Firebase المسجّل في مشروع Firebase.
لن يتم بعد ذلك كتابة أي بيانات في أي جدول "قديم" حالي يحمل اسمًا يستند إلى المعرّف في الرمز الثنائي لتطبيقك.

أمثلة على سيناريوهات المعرّفات غير المتطابقة

يُرجى العِلم أنّه تتم إضافة BigQuery تلقائيًا إلى أسماء جداول الدفعات مع _IOS أو _ANDROID للإشارة إلى النظام الأساسي للتطبيق.

المعرّفات في الرمز الثنائي لتطبيقك	المعرّفات التي تم ضبطها لتطبيقاتك على Firebase	السلوك القديم	السلوك بعد الترقية إلى البنية الأساسية الجديدة للتصدير	بدون نظام تشغيل
`foo`	`bar`	تتم الكتابة في جدول واحد يحمل اسم المعرّف في البرنامج الثنائي للتطبيق (`foo`)	يتم إنشاء جدول واحد ثم الكتابة إليه، ويتم تسميته وفقًا لمعرّف مجموعة Firebase App (`bar`)	اتّبِع الخيار 1 أو 2 الموضّح أدناه.
`foo`	‫`bar`، `qux`، إلخ	تتم الكتابة في جدول واحد يحمل اسم المعرّف في البرنامج الثنائي للتطبيق (`foo`)	يتم إنشاء* ثم كتابة البيانات في جداول متعددة تحمل أسماء المعرّفات التي تم ضبطها لتطبيقات Firebase (`bar` و`qux` وما إلى ذلك).	نفِّذ الخيار 2 الموضّح أدناه.
‫`foo`، `baz`، إلخ	`bar`	يكتب في جداول متعددة تحمل أسماء المعرّفات المتعددة في الرمز الثنائي للتطبيق (`foo` و`baz` وما إلى ذلك)	تُنشئ** ثم تكتب بيانات كل تطبيق في جدول واحد باسم المعرّف الذي تم ضبطه لتطبيق Firebase (`bar`)	لا يمكن تنفيذ أي من الخيارات. سيظل بإمكانك التمييز بين البيانات من كل تطبيق داخل الجدول الواحد باستخدام `bundle_identifier` الخاص بالتطبيق، والذي يتم تصديره مع البيانات.

^{* إذا كان المعرّف في الرمز الثنائي لتطبيقك مطابقًا لأحد المعرّفات التي تم ضبطها لتطبيق Firebase، لن تنشئ البنية الأساسية الجديدة للتصدير جدولاً جديدًا لهذا المعرّف. بدلاً من ذلك، سيواصل كتابة البيانات الخاصة بهذا التطبيق. سيتم تسجيل جميع التطبيقات الأخرى في جداول جديدة.}

^{** إذا تطابق أحد المعرّفات في الرمز الثنائي لتطبيقك مع مجموعة المعرّفات المحدّدة لتطبيق Firebase، لن تنشئ البنية الأساسية الجديدة للتصدير جدولاً جديدًا. بدلاً من ذلك، سيتم الاحتفاظ بهذا الجدول والبدء في كتابة البيانات الخاصة بجميع التطبيقات فيه.}

خيارات للحدّ من الانقطاع

الخيار 1:
استخدام الجدول الجديد الذي أنشأته البنية الأساسية الجديدة للتصدير عليك نسخ البيانات من الجدول القديم إلى الجدول الجديد.
1. في وحدة تحكّم Google Cloud، انسخ كل البيانات من الجدول القديم إلى الجدول الجديد الذي تم إنشاؤه أثناء ترقية البنية الأساسية.
2. إذا كانت لديك أي تبعيات لاحقة تعتمد على جدول الدفعات، غيِّرها لاستخدام الجدول الجديد.
ملاحظة: لن يتم كتابة البيانات الجديدة في جدولك القديم. لن يتم حذف أي بيانات سبق أن تمّت كتابتها في الجدول القديم.
الخيار 2:
إعادة ضبط الإعدادات للكتابة في الجدول القديم مرة أخرى يجب إلغاء بعض الإعدادات التلقائية في إعدادات BigQuery لتحقيق ذلك.
1. في Firebaseوحدة التحكّم، ابحث عن معرّف تطبيق Firebase (على سبيل المثال، 1:1234567890:ios:321abc456def7890) للتطبيق الذي يتضمّن اسم جدول الدفعات ومعرّفه غير المتطابقَين، واحتفظ به:
  انتقِل إلى إعدادات المشروع، ثم انتقِل إلى بطاقة تطبيقاتك للاطّلاع على جميع تطبيقات 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 بدلاً من ذلك (عادةً ما يكون هذا هو اسم الجدول القديم الذي كان التطبيق يكتب إليه باستخدام البنية الأساسية القديمة للتصدير).
    
    ملاحظة: إذا كنت تكتب سابقًا إلى جدول واحد وأصبح لديك الآن جداول متعددة بعد الترقية، يمكنك استخدام الرمز نفسه client_namespace لكل gmp_app_id ينطبق عليه. BigQuery سيؤدي ذلك إلى دمج جميع الجداول وكتابة جميع البيانات لجميع تطبيقات Firebase في هذا الجدول.
  6. احفظ التغيير في الإعدادات.
3. جدولة عملية إعادة تعبئة للأيام التي لا يتوفّر فيها بيانات في جدولك القديم
4. بعد اكتمال عملية التعبئة السابقة، احذف الجدول الجديد الذي تم إنشاؤه تلقائيًا من خلال البنية الأساسية الجديدة لعملية التصدير.

تحديد المشاكل وحلّها في Crashlytics والأسئلة الشائعة بشأنها تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

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

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

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

كيف يتم احتساب المستخدمين الذين لم تحدث لديهم أعطال؟

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

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

لماذا تظهر لي مشاكل متكرّرة في الإصدارات القديمة من التطبيق؟

الدعم الخاص بكل منصة

التوافق مع منصات Apple

ملفات dSYM غير متوفّرة أو لا يتم تحميلها

ترميز الأعطال غير صحيح

هل يمكنني استخدام Crashlytics على أجهزة macOS أو tvOS؟

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

التوافق مع Android

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

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

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

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

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

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

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

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

Kotlin

Groovy

تغييرات على الإضافة "Crashlytics"

مثال على كيفية ترقية الإضافة

Kotlin

Groovy

الدعم الخاص بـ Android NDK

الاختلافات بين تتبُّع تسلسل استدعاء الدوال البرمجية في NDK في لوحة بيانات Crashlytics وlogcat

كيف يمكنني استخدام برنامج إنشاء ملفات رموز Breakpad الثنائية الخاصة بي لحزمة NDK؟

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

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

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

دعم Unity

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

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

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

لماذا يجب أن يبلغ التطبيق عن الاستثناءات غير المعالَجة كأخطاء خطيرة؟

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

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

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

دعم عمليات الدمج

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

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

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

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

إذا لم يتطابق اسم جدول الدفعات القديم مع معرّف تطبيقك على Firebase

التعرّف على كيفية استخدام البنية الأساسية للتصدير المعرّفات لكتابة البيانات في جداول BigQuery

ماذا يحدث إذا لم يتم إصلاح هذه المشكلة قبل الترقية؟

أمثلة على سيناريوهات المعرّفات غير المتطابقة

خيارات للحدّ من الانقطاع

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

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

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

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