تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

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

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

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

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

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

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

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

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

في ما يلي التغييرات التي ستلاحظها بعد تطبيق هذه التحسينات:

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

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

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

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

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

إذا لم تظهر لك سجلات مسار التنقل، ننصحك بالتحقّق من إعدادات تطبيقك بحثًا عن Google Analytics. يجب استيفاء المتطلبات التالية:

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

يجب التأكّد من أنّك تستخدم على الأقل الإصدار التالي من حزمة تطوير البرامج (SDK) لبرنامج Firebase لنظام التشغيل Google Analytics:
‫Android: الإصدار 17.2.3 أو الإصدارات الأحدث (BoM الإصدار 24.7.1 أو الإصدارات الأحدث)

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

إذا لم تظهر لك تنبيهات السرعة، تأكَّد من أنّك تستخدم الإصدار 18.6.0 أو إصدارًا أحدث من حزمة تطوير البرامج (SDK) في Crashlytics (أو الإصدار 32.6.0 أو إصدارًا أحدث من Firebase BoM).

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

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

تأكَّد من استخدام الإصدار 18.6.0 أو إصدار أحدث من حزمة تطوير البرامج (SDK) في Crashlytics (أو الإصدار 32.6.0 أو إصدار أحدث من Firebase BoM).
تأكَّد من أنّ إعدادات جمع البيانات لا تؤثّر في جودة مقاييسك الخالية من الأعطال:
- في حال تفعيل ميزة إعداد التقارير عند الموافقة من خلال إيقاف ميزة إعداد تقارير الأعطال التلقائي، لا يمكن إرسال معلومات الأعطال إلى Crashlytics إلا من المستخدمين الذين وافقوا صراحةً على جمع البيانات. وبالتالي، ستتأثر دقة مقاييس عدم حدوث الأعطال لأنّ Crashlytics لا يتضمّن سوى معلومات الأعطال من هؤلاء المستخدمين الذين وافقوا على مشاركة البيانات (بدلاً من جميع المستخدمين). وهذا يعني أنّ مقاييسك الخاصة بعدم حدوث أعطال قد تكون أقل موثوقية وأقل تعبيرًا عن الثبات العام لتطبيقك.
- إذا كانت ميزة جمع البيانات تلقائيًا غير مفعّلة، يمكنك استخدام sendUnsentReports لإرسال التقارير المخزّنة مؤقتًا على الجهاز إلى Crashlytics. سيؤدي استخدام هذه الطريقة إلى إرسال بيانات الأعطال إلى Crashlytics، ولكن ليس بيانات الجلسات، ما يؤدي إلى عرض قيم منخفضة أو صفرية في رسومات وحدة التحكّم البيانية لمقاييس "خالٍ من الأعطال".

كيف يتم احتساب عدد المستخدمين الذين لم يواجهوا أي تعطُّل؟

اطّلِع على فهم مقاييس عدم حدوث الأعطال.

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

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

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

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

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

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

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

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

إذا كنت تستخدم lld linker من مجموعة أدوات 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
```

عدم حدوث أعطال عند استخدام 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
```

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

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

لكي يتمكّن Crashlytics من إنشاء مشاكل باستخدام امتداد الملف الصحيح، تأكَّد من أنّ تطبيقك يستخدم الإعداد التالي:

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

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

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

اعتبارًا من منتصف كانون الأول (ديسمبر) 2021، Crashlyticsأصبحنا نوفّر دعمًا محسّنًا للتطبيقات التي تستخدم لغة Kotlin.

حتى وقت قريب، لم تكن أدوات التشويش المتاحة تعرض امتداد الملف، لذا كانت أداة Crashlytics تنشئ كل مشكلة باستخدام امتداد الملف .java تلقائيًا. ومع ذلك، بدءًا من الإصدار 4.2.0 من "المكوّن الإضافي لنظام Gradle المتوافق مع Android"، يتيح R8 استخدام امتدادات الملفات.

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

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

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

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

تتيح الملاحظات لأعضاء المشروع التعليق على مشاكل معيّنة من خلال طرح أسئلة أو تقديم معلومات عن الحالة أو غير ذلك.

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

في ما يلي وصف لأذونات الوصول المطلوبة لعرض الملاحظات وكتابتها وحذفها:

يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية الاطّلاع على الملاحظات الحالية وحذفها وكتابة ملاحظات جديدة بشأن مشكلة.
- المالك أو المحرِّر للمشروع، مشرف Firebase، مشرف الجودة، أو مشرف Crashlytics
يمكن لأعضاء المشروع الذين لديهم أي من الأدوار التالية الاطّلاع على الملاحظات المنشورة بشأن إحدى المشاكل، ولكن لا يمكنهم حذف ملاحظة أو كتابتها.
- مُشاهد المشروع أو مُشاهد Firebase أو مُشاهد الجودة أو مُشاهد Crashlytics

عمليات الدمج

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

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

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

بعد ربط Crashlytics بخدمة BigQuery، يتم تلقائيًا تحديد موقع مجموعات البيانات الجديدة التي تنشئها في الولايات المتحدة، بغض النظر عن موقع مشروعك على Firebase.

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

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

لا تتوافق حزمة تطوير البرامج (NDK) الخاصة بـ Firebase Crashlytics مع ARMv5 (armeabi). تمت إزالة دعم واجهة ABI هذه اعتبارًا من الإصدار 17 من حزمة NDK.

المشاكل التي تكرّرت

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

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

في ما يلي مثال على سيناريو يوضّح كيف تصنّف Crashlytics مشكلة على أنّها تراجع:

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

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

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

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

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

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