Crashlytics সমস্যা সমাধান এবং FAQ

ক্র্যাশ-মুক্ত ব্যবহারকারী, ব্রেডক্রাম্ব লগ এবং/অথবা বেগ সতর্কতা দেখা যাচ্ছে না

আপনি যদি ক্র্যাশ-মুক্ত ব্যবহারকারী, ব্রেডক্রাম্ব লগ এবং/অথবা বেগ সতর্কতা না দেখতে পান, তাহলে আমরা Google Analytics-এর জন্য আপনার অ্যাপের কনফিগারেশন চেক করার পরামর্শ দিই।

• নিশ্চিত করুন যে আপনি আপনার Firebase প্রকল্পে Google Analytics সক্ষম করেছেন ৷

• Firebase কনসোলের ইন্টিগ্রেশন > Google Analytics পৃষ্ঠায় Google Analytics-এর জন্য ডেটা শেয়ারিং সক্ষম করা আছে কিনা তা নিশ্চিত করুন। মনে রাখবেন যে ডেটা শেয়ারিং সেটিংস Firebase কনসোলে প্রদর্শিত হয় কিন্তু Google Analytics কনসোলে পরিচালিত হয়।

• Firebase Crashlytics SDK ছাড়াও, নিশ্চিত করুন যে আপনি আপনার অ্যাপে ( iOS+ | Android ) Google Analytics-এর জন্য Firebase SDK যোগ করেছেন।

• নিশ্চিত করুন যে আপনি আপনার সমস্ত Firebase SDK-এর জন্য সর্বশেষ সংস্করণ ব্যবহার করছেন ( iOS+ | Android )৷
  বিশেষ করে দেখে নিন যে আপনি Google Analytics-এর জন্য Firebase SDK-এর ন্যূনতম নিম্নলিখিত সংস্করণগুলি ব্যবহার করছেন: iOS+ — v6.3.1+ (macOS এবং tvOS-এর জন্য v8.9.0+) | Android — v17.2.3+ (BoM v24.7.1+) ।

ইস্যু টেবিলে কিছু সমস্যার জন্য বিভিন্ন ফর্ম্যাট (এবং কখনও কখনও "ভেরিয়েন্ট") দেখা

Firebase কনসোলে আপনার ইস্যু টেবিলে তালিকাভুক্ত সমস্যার জন্য আপনি দুটি ভিন্ন ফর্ম্যাট লক্ষ্য করতে পারেন। এবং আপনি আপনার কিছু সমস্যার মধ্যে "ভেরিয়েন্ট" নামক একটি বৈশিষ্ট্যও লক্ষ্য করতে পারেন। কারণটা এখানে!

2023 সালের গোড়ার দিকে, আমরা ইভেন্টগুলিকে গ্রুপ করার জন্য একটি উন্নত বিশ্লেষণ ইঞ্জিনের পাশাপাশি একটি আপডেট করা ডিজাইন এবং নতুন সমস্যার জন্য কিছু উন্নত বৈশিষ্ট্য নিয়ে এসেছি (যেমন বৈকল্পিক!)। সমস্ত বিবরণের জন্য আমাদের সাম্প্রতিক ব্লগ পোস্টটি দেখুন, তবে আপনি হাইলাইটগুলির জন্য নীচে পড়তে পারেন।

Crashlytics আপনার অ্যাপ থেকে সমস্ত ইভেন্ট বিশ্লেষণ করে (যেমন ক্র্যাশ, নন-ফেটাল, এবং ANR) এবং ইভেন্টের গ্রুপ তৈরি করে যাকে সমস্যা বলা হয় — একটি ইস্যুতে সমস্ত ইভেন্টের ব্যর্থতার একটি সাধারণ পয়েন্ট থাকে।

এই সমস্যাগুলির মধ্যে ইভেন্টগুলিকে গোষ্ঠীভুক্ত করার জন্য, উন্নত বিশ্লেষণ ইঞ্জিন এখন ইভেন্টের অনেক দিককে দেখে, যার মধ্যে স্ট্যাক ট্রেসের ফ্রেম, ব্যতিক্রম বার্তা, ত্রুটি কোড এবং অন্যান্য প্ল্যাটফর্ম বা ত্রুটির ধরন বৈশিষ্ট্যগুলি রয়েছে৷

যাইহোক, ইভেন্টের এই গ্রুপের মধ্যে, ব্যর্থতার দিকে পরিচালিত স্ট্যাক ট্রেসগুলি ভিন্ন হতে পারে। একটি ভিন্ন স্ট্যাক ট্রেস একটি ভিন্ন মূল কারণ বোঝাতে পারে। একটি ইস্যুতে এই সম্ভাব্য পার্থক্যটি উপস্থাপন করার জন্য, আমরা এখন সমস্যার মধ্যে ভেরিয়েন্ট তৈরি করি - প্রতিটি ভেরিয়েন্ট হল একটি ইস্যুতে ইভেন্টগুলির একটি সাব-গ্রুপ যার একই ব্যর্থতা পয়েন্ট এবং একই স্ট্যাক ট্রেস রয়েছে। ভেরিয়েন্টের সাহায্যে, আপনি একটি সমস্যার মধ্যে সবচেয়ে সাধারণ স্ট্যাক ট্রেসগুলি ডিবাগ করতে পারেন এবং বিভিন্ন মূল কারণগুলি ব্যর্থতার দিকে নিয়ে যাচ্ছে কিনা তা নির্ধারণ করতে পারেন।

এই উন্নতিগুলির সাথে আপনি যা অনুভব করবেন তা এখানে:

• সংশোধিত মেটাডেটা ইস্যু সারির মধ্যে প্রদর্শিত হয়
  আপনার অ্যাপে সমস্যাগুলি বোঝা এবং ট্রাইজ করা এখন সহজ।

• কম ডুপ্লিকেট সমস্যা
  একটি লাইন নম্বর পরিবর্তনের ফলে একটি নতুন সমস্যা হয় না।

• বিভিন্ন মূল কারণ সহ জটিল সমস্যার সহজ ডিবাগিং
  একটি সমস্যার মধ্যে সবচেয়ে সাধারণ স্ট্যাক ট্রেস ডিবাগ করতে ভেরিয়েন্ট ব্যবহার করুন।

• আরও অর্থপূর্ণ সতর্কতা এবং সংকেত
  একটি নতুন সমস্যা আসলে একটি নতুন বাগ প্রতিনিধিত্ব করে।

• আরো শক্তিশালী অনুসন্ধান
  প্রতিটি সমস্যায় আরও অনুসন্ধানযোগ্য মেটাডেটা থাকে, যেমন ব্যতিক্রমের ধরন এবং প্যাকেজের নাম।

এই উন্নতিগুলি কীভাবে ঘটছে তা এখানে:

• যখন আমরা আপনার অ্যাপ থেকে নতুন ইভেন্টগুলি পাই, তখন আমরা তা একটি বিদ্যমান সমস্যার সাথে মেলে কিনা তা পরীক্ষা করব।

• যদি কোন মিল না থাকে, আমরা স্বয়ংক্রিয়ভাবে ইভেন্টে আমাদের স্মার্ট ইভেন্ট-গ্রুপিং অ্যালগরিদম প্রয়োগ করব এবং পরিমার্জিত মেটাডেটা ডিজাইনের সাথে একটি নতুন সমস্যা তৈরি করব।

এটিই প্রথম বড় আপডেট যা আমরা আমাদের ইভেন্ট গ্রুপিংয়ে তৈরি করছি। আপনার যদি প্রতিক্রিয়া থাকে বা কোনো সমস্যার সম্মুখীন হন, তাহলে অনুগ্রহ করে একটি প্রতিবেদন দাখিল করে আমাদের জানান।

কেন ANR শুধুমাত্র Android 11+ এর জন্য রিপোর্ট করা হয়?

Crashlytics অ্যান্ড্রয়েড 11 এবং উচ্চতর সংস্করণে চালিত ডিভাইসগুলি থেকে Android অ্যাপগুলির জন্য ANR রিপোর্টিং সমর্থন করে। আমরা ANR ( getHistoricalProcessExitReasons ) সংগ্রহ করতে যে অন্তর্নিহিত API ব্যবহার করি তা SIGQUIT বা ওয়াচডগ-ভিত্তিক পদ্ধতির চেয়ে বেশি নির্ভরযোগ্য। এই API শুধুমাত্র Android 11+ ডিভাইসে উপলব্ধ।

কেন কিছু ANR তাদের BuildId মিস করছে?

যদি আপনার কিছু ANR তাদের BuildId অনুপস্থিত থাকে, তাহলে নিম্নরূপ সমস্যা সমাধান করুন:

• নিশ্চিত করুন যে আপনি একটি আপ-টু-ডেট Crashlytics Android SDK এবং Crashlytics Gradle প্লাগইন সংস্করণ ব্যবহার করছেন।

  আপনি যদি Android 11 এবং কিছু Android 12 ANR-এর জন্য BuildId অনুপস্থিত থাকেন, তাহলে সম্ভবত আপনি একটি পুরানো SDK, Gradle প্লাগইন বা উভয়ই ব্যবহার করছেন। এই ANR-এর জন্য সঠিকভাবে BuildId সংগ্রহ করতে, আপনাকে নিম্নলিখিত সংস্করণগুলি ব্যবহার করতে হবে:

  • Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
  • Crashlytics Gradle প্লাগইন v2.9.4+

• আপনি আপনার শেয়ার করা লাইব্রেরিগুলির জন্য একটি অ-মানক অবস্থান ব্যবহার করছেন কিনা তা পরীক্ষা করুন৷

  আপনি যদি আপনার অ্যাপের শেয়ার করা লাইব্রেরির জন্য শুধুমাত্র BuildId গুলি না পেয়ে থাকেন, তাহলে সম্ভবত আপনি শেয়ার করা লাইব্রেরির জন্য স্ট্যান্ডার্ড, ডিফল্ট অবস্থান ব্যবহার করছেন না। যদি এটি হয়, তাহলে Crashlytics সংশ্লিষ্ট BuildId s সনাক্ত করতে সক্ষম হবে না। আমরা সুপারিশ করছি যে আপনি শেয়ার করা লাইব্রেরির জন্য স্ট্যান্ডার্ড অবস্থান ব্যবহার করার কথা বিবেচনা করুন।

• নিশ্চিত করুন যে আপনি বিল্ড প্রক্রিয়া চলাকালীন BuildId গুলি ছিনিয়ে নিচ্ছেন না৷

  মনে রাখবেন যে নিম্নলিখিত সমস্যা সমাধানের টিপস ANR এবং নেটিভ ক্র্যাশ উভয় ক্ষেত্রেই প্রযোজ্য।

  • আপনার বাইনারিগুলিতে readelf -n চালিয়ে BuildId বিদ্যমান কিনা তা পরীক্ষা করুন। যদি BuildId অনুপস্থিত থাকে, তাহলে আপনার বিল্ড সিস্টেমের জন্য পতাকাগুলিতে -Wl,--build-id যোগ করুন।

  • আপনার APK সাইজ কমানোর প্রয়াসে আপনি অনিচ্ছাকৃতভাবে BuildId গুলি খুলে ফেলছেন না তা পরীক্ষা করুন৷

  • আপনি যদি একটি লাইব্রেরির স্ট্রাইপড এবং আনস্ট্রিপড ভার্সন রাখেন, তাহলে আপনার কোডে সঠিক ভার্সনটি নির্দেশ করতে ভুলবেন না।

Crashlytics ড্যাশবোর্ড এবং Google Play Console-এ ANR রিপোর্টের মধ্যে পার্থক্য

Google Play এবং Crashlytics-এর মধ্যে ANR গণনার মধ্যে অমিল থাকতে পারে। ANR ডেটা সংগ্রহ এবং রিপোর্ট করার পদ্ধতির পার্থক্যের কারণে এটি প্রত্যাশিত। Crashlytics অ্যাপটি পরবর্তীতে শুরু হলে ANR রিপোর্ট করে, যেখানে Android Vitals ANR হওয়ার পরে ANR ডেটা পাঠায়।

উপরন্তু, Crashlytics শুধুমাত্র ANR গুলি প্রদর্শন করে যা Android 11+ চালিত ডিভাইসগুলিতে ঘটে, Google Play এর তুলনায় যা Google Play পরিষেবা এবং ডেটা সংগ্রহের সম্মতি সহ ডিভাইসগুলি থেকে ANR প্রদর্শন করে।

Crashlytics ড্যাশবোর্ড এবং logcat-এ NDK স্ট্যাক ট্রেসের মধ্যে পার্থক্য

LLVM এবং GNU টুলচেইনের স্বতন্ত্র ডিফল্ট এবং আপনার অ্যাপের বাইনারিগুলির পঠনযোগ্য অংশের জন্য চিকিত্সা রয়েছে, যা Firebase কনসোলে অসামঞ্জস্যপূর্ণ স্ট্যাক ট্রেস তৈরি করতে পারে। এটি প্রশমিত করতে, আপনার বিল্ড প্রক্রিয়াতে নিম্নলিখিত লিঙ্কার ফ্ল্যাগগুলি যুক্ত করুন:

• আপনি যদি LLVM টুলচেন থেকে lld লিঙ্কার ব্যবহার করছেন, যোগ করুন:

  -Wl,--no-rosegment
  

• আপনি যদি GNU টুলচেন থেকে ld.gold লিঙ্কার ব্যবহার করেন, তাহলে যোগ করুন:

  -Wl,--rosegment
  

আপনি যদি এখনও স্ট্যাক ট্রেস অসঙ্গতি দেখতে পান (বা যদি কোনও পতাকা আপনার টুলচেইনের সাথে প্রাসঙ্গিক না হয়), পরিবর্তে আপনার বিল্ড প্রক্রিয়াতে নিম্নলিখিতগুলি যোগ করার চেষ্টা করুন:

-fno-omit-frame-pointer

NDK-এর জন্য আমি কীভাবে আমার নিজের ব্রেকপ্যাড প্রতীক ফাইল জেনারেটর বাইনারি ব্যবহার করব?

Crashlytics প্লাগইন একটি কাস্টমাইজড ব্রেকপ্যাড প্রতীক ফাইল জেনারেটর বান্ডেল করে। আপনি যদি ব্রেকপ্যাড প্রতীক ফাইল তৈরি করার জন্য আপনার নিজস্ব বাইনারি ব্যবহার করতে পছন্দ করেন (উদাহরণস্বরূপ, যদি আপনি উত্স থেকে আপনার বিল্ড চেইনে সমস্ত নেটিভ এক্সিকিউটেবল তৈরি করতে পছন্দ করেন), এক্সিকিউটেবলের পাথ নির্দিষ্ট করতে ঐচ্ছিক symbolGeneratorBinary এক্সটেনশন সম্পত্তি ব্যবহার করুন।

আপনি ব্রেকপ্যাড সিম্বল ফাইল জেনারেটর বাইনারি দুটি উপায়ের একটিতে পাথ নির্দিষ্ট করতে পারেন:

• বিকল্প 1 : আপনার build.gradle ফাইলে firebaseCrashlytics এক্সটেনশনের মাধ্যমে পথটি নির্দিষ্ট করুন

  আপনার অ্যাপ-স্তরের build.gradle ফাইলে নিম্নলিখিত যোগ করুন:

  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.symbolGeneratorBinary প্রপার্টি ব্যবহার করে এক্সিকিউটেবলের পথ নির্দিষ্ট করতে পারেন।

  আপনি ম্যানুয়ালি আপনার Gradle বৈশিষ্ট্য ফাইল আপডেট করতে পারেন বা কমান্ড লাইনের মাধ্যমে ফাইল আপডেট করতে পারেন। উদাহরণস্বরূপ, কমান্ড লাইনের মাধ্যমে পথটি নির্দিষ্ট করতে, নিম্নলিখিতগুলির মতো একটি কমান্ড ব্যবহার করুন:

  ./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
    -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

ডেক্সগার্ডের সাথে ক্র্যাশ হচ্ছে না

আপনি যদি নিম্নলিখিত ব্যতিক্রমটি দেখতে পান, তাহলে সম্ভবত আপনি DexGuard-এর এমন একটি সংস্করণ ব্যবহার করছেন যা Firebase Crashlytics SDK-এর সাথে সামঞ্জস্যপূর্ণ নয়:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

এই ব্যতিক্রম আপনার অ্যাপ ক্র্যাশ করে না কিন্তু ক্র্যাশ রিপোর্ট পাঠাতে বাধা দেয়। এটি ঠিক করতে:

1. আপনি সর্বশেষ DexGuard 8.x রিলিজ ব্যবহার করছেন তা নিশ্চিত করুন। সর্বশেষ সংস্করণে Firebase Crashlytics SDK-এর জন্য প্রয়োজনীয় নিয়ম রয়েছে।

2. আপনি যদি আপনার DexGuard সংস্করণ পরিবর্তন করতে না চান, তাহলে আপনার অস্পষ্টতা নিয়মে নিম্নলিখিত লাইন যোগ করার চেষ্টা করুন (আপনার DexGuard কনফিগারেশন ফাইলে):

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct
   

কেন আমি .kt ফাইল থেকে .java সমস্যা হিসাবে লেবেল থেকে ক্র্যাশ দেখতে পাচ্ছি?

যখন একটি অ্যাপ এমন একটি অস্পষ্টকারী ব্যবহার করে যা ফাইল এক্সটেনশন প্রকাশ করে না, তখন Crashlytics ডিফল্টরূপে .java ফাইল এক্সটেনশনের সাথে প্রতিটি সমস্যা তৈরি করে।

যাতে Crashlytics সঠিক ফাইল এক্সটেনশনের সাথে সমস্যা তৈরি করতে পারে, নিশ্চিত করুন যে আপনার অ্যাপ নিম্নলিখিত সেটআপ ব্যবহার করছে:

• Android Gradle 4.2.0 বা উচ্চতর ব্যবহার করে
• অস্পষ্টতা চালু থাকা অবস্থায় R8 ব্যবহার করে। R8 এ আপনার অ্যাপ আপডেট করতে, এই ডকুমেন্টেশন অনুসরণ করুন।

মনে রাখবেন যে উপরে বর্ণিত সেটআপে আপডেট করার পরে, আপনি নতুন .kt সমস্যাগুলি দেখতে শুরু করতে পারেন যা বিদ্যমান .java সমস্যাগুলির সদৃশ। সেই পরিস্থিতি সম্পর্কে আরও জানতে FAQ দেখুন।

আমি কেন .kt সমস্যাগুলি দেখতে পাচ্ছি যেগুলি বিদ্যমান .java সমস্যাগুলির নকল?

2021 সালের ডিসেম্বরের মাঝামাঝি থেকে, ক্র্যাশলিটিক্স কোটলিন ব্যবহার করে এমন অ্যাপ্লিকেশনগুলির জন্য সমর্থন উন্নত করেছে।

সম্প্রতি অবধি, উপলব্ধ অস্পষ্টকারীরা ফাইল এক্সটেনশনটি প্রকাশ করেনি, তাই ক্র্যাশলিটিক্স ডিফল্টরূপে একটি .java ফাইল এক্সটেনশনের সাথে প্রতিটি সমস্যা তৈরি করেছে। যাইহোক, Android Gradle 4.2.0 অনুযায়ী, R8 ফাইল এক্সটেনশন সমর্থন করে।

এই আপডেটের মাধ্যমে, Crashlytics এখন নির্ধারণ করতে পারে যে অ্যাপের মধ্যে ব্যবহৃত প্রতিটি ক্লাস কোটলিনে লেখা আছে কিনা এবং ইস্যু স্বাক্ষরে সঠিক ফাইলের নাম অন্তর্ভুক্ত করা হয়েছে। আপনার অ্যাপে নিম্নলিখিত সেটআপ থাকলে ক্র্যাশগুলি এখন সঠিকভাবে .kt ফাইলগুলিতে (যথাযথ হিসাবে) দায়ী করা হয়েছে:

• আপনার অ্যাপ Android Gradle 4.2.0 বা উচ্চতর ব্যবহার করে।
• অস্পষ্টতা চালু থাকা অবস্থায় আপনার অ্যাপ R8 ব্যবহার করে।

যেহেতু নতুন ক্র্যাশগুলি এখন তাদের ইস্যু স্বাক্ষরে সঠিক ফাইল এক্সটেনশন অন্তর্ভুক্ত করে, আপনি নতুন .kt সমস্যাগুলি দেখতে পারেন যা আসলে বিদ্যমান .java লেবেলযুক্ত সমস্যাগুলির নকল। Firebase কনসোলে, যদি একটি নতুন .kt সমস্যা বিদ্যমান .java লেবেলযুক্ত সমস্যার একটি সম্ভাব্য অনুলিপি হয় তবে আমরা সনাক্ত করার এবং আপনার সাথে যোগাযোগ করার চেষ্টা করি৷

ক্র্যাশ-মুক্ত ব্যবহারকারীদের কীভাবে গণনা করা হয়?

ক্র্যাশ-মুক্ত মানটি এমন ব্যবহারকারীদের শতাংশের প্রতিনিধিত্ব করে যারা আপনার অ্যাপের সাথে জড়িত কিন্তু একটি নির্দিষ্ট সময়ের মধ্যে ক্র্যাশ হয়নি ।

ক্র্যাশ-মুক্ত ব্যবহারকারীর শতাংশ গণনা করার সূত্রটি এখানে। এর ইনপুট মান Google Analytics দ্বারা প্রদান করা হয়.

CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100

• যখন একটি ক্র্যাশ ঘটে, তখন Google Analytics একটি app_exception ইভেন্ট টাইপ পাঠায় এবং CRASHED_USERS সেই ইভেন্ট প্রকারের সাথে যুক্ত ব্যবহারকারীর সংখ্যা উপস্থাপন করে।

• Crashlytics ড্যাশবোর্ডের উপরের-ডানদিকে ড্রপডাউন মেনু থেকে আপনি যে সময়কালে নির্বাচন করেছেন সেই সময়ের মধ্যে আপনার অ্যাপের সাথে জড়িত মোট ব্যবহারকারীদের ALL_USERS প্রতিনিধিত্ব করে।

ক্র্যাশ-মুক্ত ব্যবহারকারীর শতাংশ সময়ের সাথে একটি সমষ্টি , গড় নয়।

উদাহরণস্বরূপ, কল্পনা করুন আপনার অ্যাপের তিনজন ব্যবহারকারী আছে; আমরা তাদের ব্যবহারকারী A, User B, এবং User C বলব। নিচের সারণীটি দেখায় যে কোন ব্যবহারকারীরা প্রতিদিন আপনার অ্যাপের সাথে জড়িত ছিলেন এবং সেই দিন কোন ব্যবহারকারীর ক্র্যাশ হয়েছিল:

• বুধবার, আপনার ক্র্যাশ-মুক্ত ব্যবহারকারীর শতাংশ হল 50% (2 জনের মধ্যে 1 জন ব্যবহারকারী ক্র্যাশ-মুক্ত ছিল)।
  আপনার দুইজন ব্যবহারকারী বুধবার আপনার অ্যাপের সাথে জড়িত, কিন্তু তাদের মধ্যে শুধুমাত্র একজনের (ব্যবহারকারী B) কোনো ক্র্যাশ হয়নি।

• গত 2 দিনের জন্য, আপনার ক্র্যাশ-মুক্ত ব্যবহারকারীর শতাংশ হল 33.3% (3 জনের মধ্যে 1 জন ব্যবহারকারী ক্র্যাশ-মুক্ত ছিল)।
  আপনার তিনজন ব্যবহারকারী গত দুই দিনে আপনার অ্যাপের সাথে জড়িত, কিন্তু তাদের মধ্যে শুধুমাত্র একজন (ব্যবহারকারী সি) কোনো ক্র্যাশ হয়নি।

• গত 3 দিনের জন্য, আপনার ক্র্যাশ-মুক্ত ব্যবহারকারীর শতাংশ হল 0% (3টির মধ্যে 0 জন ব্যবহারকারী ক্র্যাশ-মুক্ত ছিল)।
  আপনার তিনজন ব্যবহারকারী গত তিন দিনে আপনার অ্যাপের সাথে জড়িত, কিন্তু তাদের মধ্যে শূন্যের কোনো ক্র্যাশ হয়নি।

কে একটি ইস্যুতে নোট দেখতে, লিখতে এবং মুছতে পারে?

নোটগুলি প্রকল্পের সদস্যদের প্রশ্ন, স্ট্যাটাস আপডেট ইত্যাদির সাথে নির্দিষ্ট বিষয়ে মন্তব্য করার অনুমতি দেয়।

যখন কোনও প্রকল্প সদস্য একটি নোট পোস্ট করে, তখন এটি তাদের Google অ্যাকাউন্টের ইমেলের সাথে লেবেল করা হয়। এই ইমেল ঠিকানাটি নোটের সাথে, নোটটি দেখার অ্যাক্সেস সহ সমস্ত প্রকল্প সদস্যদের কাছে দৃশ্যমান।

নিম্নলিখিতগুলি নোটগুলি দেখতে, লিখতে এবং মুছতে প্রয়োজনীয় অ্যাক্সেস বর্ণনা করে:

• নিম্নলিখিত যেকোনও ভূমিকা সহ প্রকল্প সদস্যরা বিদ্যমান নোটগুলি দেখতে এবং মুছে ফেলতে পারেন এবং একটি সমস্যায় নতুন নোট লিখতে পারেন।

  • প্রকল্পের মালিক বা সম্পাদক , ফায়ারবেস অ্যাডমিন , কোয়ালিটি অ্যাডমিন বা ক্র্যাশলাইটিক্স অ্যাডমিন

• নিম্নলিখিত ভূমিকাগুলির মধ্যে যেকোনও প্রকল্পের সদস্যরা একটি ইস্যুতে পোস্ট করা নোটগুলি দেখতে পারেন, কিন্তু তারা একটি নোট মুছতে বা লিখতে পারবেন না।

  • প্রজেক্ট ভিউয়ার , ফায়ারবেস ভিউয়ার , কোয়ালিটি ভিউয়ার বা ক্র্যাশলাইটিক্স ভিউয়ার

অ্যাপটি Google মোবাইল বিজ্ঞাপন SDKও ব্যবহার করে কিন্তু ক্র্যাশ পাচ্ছে না

আপনার প্রোজেক্ট যদি Google Mobile Ads SDK-এর পাশাপাশি Crashlytics ব্যবহার করে, তাহলে ব্যতিক্রম হ্যান্ডলারদের নিবন্ধন করার সময় ক্র্যাশ রিপোর্টাররা হস্তক্ষেপ করছে। সমস্যা সমাধানের জন্য, disableSDKCrashReporting কল করে মোবাইল বিজ্ঞাপন SDK-এ ক্র্যাশ রিপোর্টিং বন্ধ করুন।

আমার BigQuery ডেটাসেট কোথায় অবস্থিত?

আপনি BigQuery-এর সাথে Crashlytics লিঙ্ক করার পরে, আপনার তৈরি করা নতুন ডেটাসেটগুলি স্বয়ংক্রিয়ভাবে মার্কিন যুক্তরাষ্ট্রে অবস্থিত হবে, আপনার Firebase প্রকল্পের অবস্থান নির্বিশেষে।

Crashlytics কি আরমেবিকে সমর্থন করে?

Firebase Crashlytics NDK ARMv5 (armeabi) সমর্থন করে না। NDK r17 হিসাবে এই ABI-এর জন্য সমর্থন সরানো হয়েছে।

একটি regressed সমস্যা কি?

আপনি পূর্বে সমস্যাটি বন্ধ করার সময় একটি সমস্যাটি রিগ্রেশন হয়েছে কিন্তু Crashlytics একটি নতুন প্রতিবেদন পায় যে সমস্যাটি আবার ঘটেছে। Crashlytics স্বয়ংক্রিয়ভাবে এই প্রত্যাবর্তিত সমস্যাগুলি পুনরায় খোলে যাতে আপনি সেগুলিকে আপনার অ্যাপের জন্য উপযুক্ত হিসাবে সমাধান করতে পারেন।

এখানে একটি উদাহরণের দৃশ্য যা ব্যাখ্যা করে যে কীভাবে ক্র্যাশলিটিক্স একটি সমস্যাকে রিগ্রেশন হিসাবে শ্রেণীবদ্ধ করে:

1. প্রথমবারের মতো, Crashlytics ক্র্যাশ "A" সম্পর্কে একটি ক্র্যাশ রিপোর্ট পায়৷ Crashlytics সেই ক্র্যাশের জন্য একটি সংশ্লিষ্ট সমস্যা খোলে (ইস্যু "A")।
2. আপনি এই বাগটি দ্রুত ঠিক করুন, সমস্যা "A" বন্ধ করুন এবং তারপর আপনার অ্যাপের একটি নতুন সংস্করণ প্রকাশ করুন৷
3. আপনি সমস্যাটি বন্ধ করার পরে Crashlytics ইস্যু "A" সম্পর্কে আরেকটি প্রতিবেদন পায়।
   • প্রতিবেদনটি যদি এমন কোনো অ্যাপ সংস্করণ থেকে হয় যা Crashlytics জানত যে আপনি যখন সমস্যাটি বন্ধ করেছিলেন (অর্থাৎ সংস্করণটি কোনও ক্র্যাশের জন্য একটি ক্র্যাশ রিপোর্ট পাঠিয়েছিল), তাহলে Crashlytics সমস্যাটিকে প্রত্যাবর্তন হিসাবে বিবেচনা করবে না। বিষয়টি বন্ধ থাকবে।
   • রিপোর্টটি যদি এমন একটি অ্যাপ সংস্করণ থেকে হয় যা Crashlytics জানত না যে আপনি কখন সমস্যাটি বন্ধ করেছিলেন (অর্থাৎ সংস্করণটি কোনও ক্র্যাশের জন্য কোনও ক্র্যাশ রিপোর্ট পাঠায়নি ), তাহলে Crashlytics বিবেচনা করে যে সমস্যাটি প্রত্যাবর্তিত হয়েছে এবং সমস্যাটি আবার খুলবে .

যখন একটি সমস্যা রিগ্রেস হয়, তখন আমরা একটি রিগ্রেশন শনাক্তকরণ সতর্কতা পাঠাই এবং সমস্যাটিতে একটি রিগ্রেশন সিগন্যাল যোগ করি যাতে আপনাকে জানানো হয় যে Crashlytics সমস্যাটি আবার খুলেছে। আপনি যদি আমাদের রিগ্রেশন অ্যালগরিদমের কারণে কোনো সমস্যা পুনরায় খুলতে না চান, তাহলে সমস্যাটিকে বন্ধ করার পরিবর্তে "নিঃশব্দ" করুন।

কেন আমি পুরানো অ্যাপ সংস্করণগুলির জন্য প্রত্যাবর্তিত সমস্যাগুলি দেখছি?

যদি কোনও রিপোর্ট কোনও পুরানো অ্যাপ সংস্করণ থেকে হয় যেটি আপনি সমস্যাটি বন্ধ করার সময় কোনও ক্র্যাশ রিপোর্ট পাঠাননি, তাহলে Crashlytics সমস্যাটিকে প্রত্যাবর্তন বলে বিবেচনা করে এবং সমস্যাটি আবার খুলবে।

এই পরিস্থিতি নিম্নলিখিত পরিস্থিতিতে ঘটতে পারে: আপনি একটি বাগ সংশোধন করেছেন এবং আপনার অ্যাপের একটি নতুন সংস্করণ প্রকাশ করেছেন, কিন্তু আপনার কাছে এখনও বাগ সংশোধন ছাড়াই পুরানো সংস্করণে ব্যবহারকারীরা আছে৷ যদি, ঘটনাক্রমে, আপনি সমস্যাটি বন্ধ করার সময় সেই পুরানো সংস্করণগুলির মধ্যে একটি কখনই কোনও ক্র্যাশ রিপোর্ট না পাঠায়, এবং সেই ব্যবহারকারীরা বাগটির সম্মুখীন হতে শুরু করে, তাহলে সেই ক্র্যাশ রিপোর্টগুলি একটি প্রত্যাবর্তিত সমস্যাকে ট্রিগার করবে৷

আপনি যদি আমাদের রিগ্রেশন অ্যালগরিদমের কারণে কোনো সমস্যা পুনরায় খুলতে না চান, তাহলে সমস্যাটিকে বন্ধ করার পরিবর্তে "নিঃশব্দ" করুন।