Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

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

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

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

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

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

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

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

في ما يلي الميزات التي ستتوفّر لك بعد إجراء هذه التحسينات:

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

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

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

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

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

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

لقد فعّلت Google Analytics في مشروع Firebase.
لقد فعّلت مشاركة البيانات لـ Google Analytics. مزيد من المعلومات عن هذا الإعداد في إدارة إعدادات مشاركة البيانات في "إحصاءات Google"
لقد أضفت إلى تطبيقك حزمة تطوير البرامج (SDK) لمنصة Firebase لنظام التشغيل Google Analytics: iOS+ | Android | Flutter | Unity.
يجب إضافة حزمة تطوير البرامج هذه بالإضافة إلى حزمة تطوير البرامج 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 تقريرًا عن عطل في Crash "A". يفتح Crashlytics مشكلة ذات صلة بهذا العطل (المشكلة "A").
يمكنك إصلاح هذا الخطأ سريعًا وإغلاق المشكلة "أ"، ثم إصدار نسخة جديدة من تطبيقك.
تلقّي Crashlytics تقريرًا آخر بشأن المشكلة "أ" بعد إغلاقك لها
- إذا كان التقرير من إصدار تطبيق Crashlytics على علم به عند إغلاق المشكلة (ما يعني أنّ الإصدار أرسل تقريرًا عن تعطُّل أي تعطُّل على الإطلاق)، لن تعتبر Crashlytics المشكلة متكرّرة. سيظل الطلب مغلقًا.
- إذا كان التقرير من إصدار تطبيق Crashlytics لم يكن على علم به عند إغلاق المشكلة (ما يعني أنّ الإصدار لم يرسل أي تقرير تعطل لأي تعطل على الإطلاق)، ستعتبر Crashlytics المشكلة قد تكرّرت وسيتم إعادة فتحها.

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

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

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

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

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

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

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

الأنظمة الأساسية المتوافقة مع Apple

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

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

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

التوافق مع Android

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

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

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

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

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

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

إذا كانتBuildIds فقط غير متوفّرة في المكتبات المشتركة لتطبيقك، من المحتمل أنّك لا تستخدم الموقع الجغرافي العادي التلقائي للمكتبات المشتركة. وفي هذه الحالة، قد لا يتمكّن Crashlytics من تحديد موقع BuildIds المرتبطة. ننصحك باستخدام الموقع الجغرافي العادي للمكتبات المشتركة.
تأكَّد من عدم إزالة 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 من المكوّن الإضافي لنظام 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:

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

Kotlin

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

Groovy

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.

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

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 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).

دعم 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: تأكَّد من أنّك أعددت الأمر Firebase لواجهة سطر الأوامر crashlytics:symbols:upload ونفّذته لإنشاء ملف الرموز وتحميله.
  
  يجب تنفيذ أمر واجهة سطر الأوامر هذا في كل مرة تنشئ فيها إصدارًا أو أي إصدار تريد عرض عمليات تتبُّع تسلسل استدعاء الدوال البرمجية مع رموز في وحدة تحكّم 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.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.
بعد إنشاء مجموعة بيانات، لا يمكن تغيير موقعها الجغرافي، ولكن يمكنك نسخها إلى موقع جغرافي آخر أو نقلها (إعادة إنشائها) يدويًا في موقع جغرافي آخر. لمزيد من المعلومات، اطّلِع على مقالة تغيير الموقع الجغرافي لعمليات التصدير الحالية.

هل تواجه مشاكل بعد الترقية إلى البنية الأساسية الجديدة للتصدير في ‎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 (`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 ينطبق عليه ذلك. سيؤدي ذلك بشكل أساسي إلى دمج جميع الجداول وكتابة جميع البيانات لجميع تطبيقات Firebase في جدول واحد.
    BigQuery
  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` حالية؟