تستخدم 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 أو إصدار أحدث (BoM الإصدار 24.7.1 أو إصدار أحدث).

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

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

عدم تلقّي تنبيهات "Crashlytics" (الأذونات)

لتلقّي تنبيهات "Crashlytics" أو ضبطها، يجب أن يحصل أعضاء المشروع على أذونات "إدارة الهوية وإمكانية الوصول" المطلوبة. يمكنك إدارة إعدادات التنبيهات وضبط الإعدادات المفضّلة للتنبيهات في حسابك في وحدة تحكّم "Firebase" في صفحة الإعدادات > التنبيهات.

يعرض الجدول التالي الأذونات المطلوبة والأدوار المحدّدة مسبقًا التي تتضمّن هذه الأذونات تلقائيًا:

الميزة	الإذن المطلوب لتلقّي التنبيه	الأدوار التي تتضمّن الإذن المطلوب تلقائيًا
Crashlytics - تنبيهات تطبيق الأجهزة الجوّالة	`firebase.projects.update`	المالك محرِّر مشرف Firebase
Crashlytics - تنبيهات تطبيق الويب	`monitoring.alertPolicies.create` `monitoring.alertPolicies.update` `monitoring.notificationChannels.create`	المالك محرِّر محرِّر المراقبة

لمزيد من المعلومات حول ضبط التنبيهات، يُرجى الاطّلاع على المقالة ضبط تنبيهات Crashlytics وتلقّيها. لمزيد من المعلومات عن أدوار وأذونات "إدارة الهوية وإمكانية الوصول"، يُرجى الاطّلاع على الأذونات والوصول إلى Firebase.

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

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

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

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

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

يتطلب الإصدار 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.

الدعم على الويب

يظهر الخطأ `Component crashlytics has not been registered yet`

عند استخدام حزمة @firebase/crashlytics، لا تخلط بين مساحات الأسماء المعيارية في عمليات الاستيراد. يؤدي استيراد initializeApp من firebase/app أثناء استيراد getCrashlytics من @firebase/crashlytics إلى تحميل حِزم لِسجلَّين داخليَّين منفصلَين، ما يؤدي إلى حدوث أخطاء مثل Component crashlytics has not been registered yet.

في ما يلي كيفية منع تعارضات السجلّات في الحِزم المزدوجة:

توحيد جميع عمليات استيراد Firebase في مشروعك لاستخدام مساحة الاسم @firebase/ ذات النطاق المحدّد (على سبيل المثال، @firebase/app و@firebase/crashlytics).

إذا كان تطبيقك يستخدم Vite، عليك إزالة تكرار @firebase/app بشكل صريح في ملف vite.config.ts:

// vite.config.ts
import { defineConfig } from 'vite';

export default defineConfig({
  resolve: {
    dedupe: ['@firebase/app']
  }
});

خطأ في تجميع TypeScript مع تفعيل `verbatimModuleSyntax`

غالبًا ما تفعّل إعدادات TypeScript الحديثة (مثل نماذج Vite وAngular) "verbatimModuleSyntax": true في tsconfig.json. عند تفعيل هذا الإعداد، يؤدي استيراد واجهة TypeScript باستخدام استيراد قيمة عادية إلى حدوث خطأ في التجميع.

استخدِم عمليات استيراد type صريحة عند استيراد واجهات TypeScript، مثل FirebaseApp أو Crashlytics:

import { initializeApp, type FirebaseApp } from '@firebase/app';
import { getCrashlytics, type Crashlytics } from '@firebase/crashlytics';

دعم Unity

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

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

تأكَّد من استخدام الإصدار 8.6.1 أو إصدار أحدث من حزمة تطوير البرامج (SDK) لمنصة Unity في Crashlytics.
تأكَّد من إعداد واجهة سطر الأوامر (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" الإبلاغ عن الاستثناءات غير المكتشَفة على أنّها أخطاء فادحة (بدءًا من الإصدار 10.4.0 من حزمة تطوير البرامج (SDK) لمنصة Unity). تساعد الأسئلة الشائعة التالية في شرح الأساس المنطقي وأفضل الممارسات لاستخدام هذه الميزة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الخيار 1: الطباعة في وحدة تحكّم Unity، ولكن بدون إرسال تقرير إلى Crashlytics، أثناء التطوير أو تحديد المشاكل وحلّها
- يمكنك الطباعة إلى وحدة تحكّم Unity باستخدام Debug.Log(exception) وDebug.LogWarning(exception) وDebug.LogError(exception)، والتي تطبع محتوى الاستثناء إلى وحدة تحكّم Unity ولا تعيد طرح الاستثناء.
الخيار 2: التحميل إلى Crashlytics لإعداد تقارير موحّدة في لوحة بيانات Crashlytics للحالات التالية:
- إذا كان الاستثناء يستحق التسجيل لتصحيح أخطاء حدث Crashlytics لاحق محتمل، استخدِم Crashlytics.Log(exception.ToString()).
- إذا كان يجب الإبلاغ عن استثناء إلى Crashlytics على الرغم من رصده ومعالجته، استخدِم Crashlytics.LogException(exception) لتسجيله كحدث غير خطير.

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

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

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

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

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

دعم بشأن عمليات الدمج

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

المعرّفات في الملف الثنائي لتطبيقك	المعرّفات التي تم ضبطها لتطبيقات Firebase	السلوك القديم	السلوك بعد الترقية إلى البنية الأساسية الجديدة للتصدير	بدون نظام تشغيل
`foo`	`bar`	يكتب في جدول واحد يحمل اسم المعرّف في ملف التطبيق الثنائي (`foo`)	يتم إنشاء جدول واحد ثم الكتابة فيه، ويتم تسميته باسم المعرّف الذي تم ضبطه لتطبيق Firebase (`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 والأسئلة الشائعة بشأنها تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

عدم ظهور سجلّات خطوات المستخدم

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

عدم تلقّي تنبيهات "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؟

الدعم على الويب

يظهر الخطأ Component crashlytics has not been registered yet

خطأ في تجميع TypeScript مع تفعيل verbatimModuleSyntax

دعم Unity

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

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

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

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

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

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

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

دعم بشأن عمليات الدمج

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

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

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

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

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

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

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

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

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

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

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

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

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

يظهر الخطأ `Component crashlytics has not been registered yet`

خطأ في تجميع TypeScript مع تفعيل `verbatimModuleSyntax`