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

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

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

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

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

عدم ظهور مقاييس "النسبة المئوية للجلسات التي لم يحدث فيها أي عطل" (أو ظهور مقاييس غير موثوقة)

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

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

ترميز الأعطال غير دقيق

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

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

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

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

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

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

دعم Android

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

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

لماذا لا تظهر `BuildId` في بعض أخطاء ANR؟

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

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

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

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

يُرجى العِلم أنّ النصائح التالية لتحديد المشاكل وحلّها تنطبق على كل من أخطاء ANR والأعطال الداخلية في نظام التشغيل.
- تحقَّق من توفّر BuildId من خلال تشغيل readelf -n على الملفات الثنائية. إذا لم تكن BuildIds متوفّرة، أضِف -Wl,--build-id إلى العلامات لنظام الإصدار.
- تأكَّد من أنّك لا تزيل ملفات BuildId عن غير قصد في محاولة لتقليل حجم حزمة APK.
- إذا كنت تحتفظ بنسخ مجرّدة وغير مجرّدة من مكتبة، تأكَّد من الإشارة إلى النسخة الصحيحة في الرمز البرمجي.

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

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

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

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

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

ليتمكّن "Crashlytics" من إنشاء المشاكل باستخدام امتداد الملف الصحيح، يُرجى التأكّد من أنّ تطبيقك يستخدم الإعدادات التالية:

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

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

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

اعتبارًا من منتصف ديسمبر 2021، تم تحسين دعم Crashlytics للتطبيقات التي تستخدم Kotlin.

حتى وقت قريب، لم تكن أدوات التشويش المتاحة تكشف عن امتداد الملف، لذلك كانت أداة Crashlytics تنشئ كل مشكلة بامتداد ملف .java تلقائيًا. ومع ذلك، اعتبارًا من الإصدار 4.2.0 من المكوّن الإضافي لنظام Gradle المتوافق مع Android، يتيح 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

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

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

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

الإصدار 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 هذه اعتبارًا من الإصدار r17 من NDK.

دعم Unity

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

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

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

يجب تشغيل أمر واجهة سطر الأوامر (CLI) هذا في كل مرة يتم فيها إنشاء بنية إصدار أو أي بنية تريد الاطّلاع على تتبُّع تسلسل استدعاء الدوال البرمجية المرمَّزة لها في وحدة تحكّم 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 لإنشاء ملف الرموز وتحميله.
  
  يجب تشغيل أمر واجهة سطر الأوامر (CLI) هذا في كل مرة يتم فيها إنشاء بنية إصدار أو أي بنية تريد الاطّلاع على تتبُّع تسلسل استدعاء الدوال البرمجية المرمَّزة لها في وحدة تحكّم Firebase. يمكنك الاطّلاع على مزيد من المعلومات في مقالة الحصول على تقارير أعطال قابلة للقراءة.

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

يمكن لـ "Crashlytics" الإبلاغ عن الاستثناءات غير المكتشفة على أنّها أخطاء فادحة (بدءًا من الإصدار v10.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 (`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 والإصدارات الأحدث فقط؟

لماذا لا تظهر BuildId في بعض أخطاء ANR؟

الاختلافات بين تقارير 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 والأسئلة الشائعة بشأنها

لماذا لا تظهر `BuildId` في بعض أخطاء ANR؟

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

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