تحديد المشاكل وحلّها في 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 تقرير عطل بشأن Crash "A". يؤدي Crashlytics إلى فتح مشكلة ذات صلة بهذا التعطُّل (المشكلة "أ").
يمكنك إصلاح هذا الخطأ سريعًا وإغلاق المشكلة "أ"، ثم طرح إصدار جديد من تطبيقك.
تتلقّى 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 أو مراقبة الأداء. لا تتوفّر واجهة برمجة التطبيقات هذه إلا على أجهزة Android 11 والإصدارات الأحدث.

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

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

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

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

يُرجى العِلم أنّ نصائح تحديد المشاكل وحلّها التالية تنطبق على أخطاء 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

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

تأكَّد من استخدام أحدث إصدار من 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 التغييرات غير المتوافقة التالية:

تمت إزالة الإضافة من حزمة 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 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). تمت إزالة دعم واجهة التطبيق الثنائية هذه اعتبارًا من الإصدار 17 من NDK.

دعم Unity

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

إذا كنت تستخدم 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 CLI 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 لاحق، استخدِم 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 (أيّهما أحدث).
تسمّي البنية الأساسية الجديدة جداول الدفعات باستخدام المعرّفات التي تم ضبطها لتطبيقات Firebase في مشروع Firebase.BigQuery
- كانت البنية الأساسية القديمة تكتب البيانات في جداول مجمّعة بأسماء تستند إلى معرِّفات الحِزم أو أسماء الحِزم في الرمز الثنائي لتطبيقك.
- تكتب البنية الأساسية الجديدة البيانات في جداول مجمّعة بأسماء تستند إلى أرقام تعريف الحِزم أو أسماء الحِزم المحدّدة لتطبيقات 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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