এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

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

এই পৃষ্ঠায় Crashlytics ব্যবহারের সমস্যা সমাধানে সাহায্য এবং প্রায়শই জিজ্ঞাসিত প্রশ্নের উত্তর দেওয়া হয়েছে। আপনি যা খুঁজছেন তা যদি খুঁজে না পান বা অতিরিক্ত সাহায্যের প্রয়োজন হয়, তাহলে Firebase সাপোর্টের সাথে যোগাযোগ করুন।

এই পাতায় আপনি নিম্নলিখিত ধরনের বিষয়গুলো সম্পর্কে তথ্য পেতে পারেন:

সাধারণ সমস্যা সমাধান , যার মধ্যে রয়েছে Firebase কনসোলে ডেটা প্রদর্শন বা ডেটা নিয়ে কাজ করা সংক্রান্ত প্রশ্ন এবং পুনরায় সমাধান হওয়া সমস্যা সম্পর্কিত প্রশ্ন।
প্ল্যাটফর্ম-ভিত্তিক সহায়তা , যার মধ্যে অ্যাপল প্ল্যাটফর্ম , অ্যান্ড্রয়েড এবং ইউনিটি সম্পর্কিত প্রশ্নাবলী অন্তর্ভুক্ত।
ইন্টিগ্রেশন সহায়তা , যার মধ্যে BigQuery সম্পর্কিত প্রশ্নও অন্তর্ভুক্ত।

সাধারণ সমস্যা সমাধান/প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

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

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

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

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

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

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

এই উন্নতিগুলোর ফলে আপনি যা অনুভব করবেন তা হলো:

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

এই উন্নতিগুলো যেভাবে বাস্তবায়িত হচ্ছে তা নিচে দেওয়া হলো:

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

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

ব্রেডক্রাম্ব লগ দেখতে না পাওয়া

আপনি যদি ব্রেডক্রাম্ব লগ দেখতে না পান ( iOS+ | Android | Flutter | Unity ), তাহলে আমরা আপনার অ্যাপের Google Analytics কনফিগারেশন পরীক্ষা করার পরামর্শ দিচ্ছি। নিশ্চিত করুন যে আপনি নিম্নলিখিত শর্তগুলো পূরণ করছেন:

আপনি আপনার Firebase প্রজেক্টে Google Analytics চালু করেছেন ।
আপনি Google Analytics জন্য ডেটা শেয়ারিং সক্ষম করেছেন। এই সেটিংটি সম্পর্কে আরও জানতে 'আপনার অ্যানালিটিক্স ডেটা শেয়ারিং সেটিংস পরিচালনা করুন' (Manage your Analytics data sharing settings) দেখুন।
আপনি আপনার অ্যাপে Google Analytics জন্য Firebase SDK যোগ করেছেন: iOS+ | Android | Flutter | Unity ।
এই SDK-টি Crashlytics SDK-এর পাশাপাশি অবশ্যই যোগ করতে হবে।
আপনি আপনার অ্যাপে ব্যবহৃত সমস্ত প্রোডাক্টের ( iOS+ | Android | Flutter | Unity ) জন্য সর্বশেষ Firebase SDK ভার্সন ব্যবহার করছেন।
অ্যাপল প্ল্যাটফর্ম এবং অ্যান্ড্রয়েড অ্যাপের ক্ষেত্রে, বিশেষ করে নিশ্চিত করুন যে আপনি Google Analytics জন্য ফায়ারবেস এসডিকে-এর ন্যূনতম নিম্নলিখিত সংস্করণটি ব্যবহার করছেন: iOS+ — সংস্করণ ৬.৩.১+ (macOS এবং tvOS-এর জন্য সংস্করণ ৮.৯.০+) | Android — v17.2.3+ ( BoM v24.7.1+)।

বেগের সতর্কতা দেখা যাচ্ছে না

আপনি যদি বেগের সতর্কতা দেখতে না পান, তাহলে নিশ্চিত করুন যে আপনি ব্যবহার করছেনক্র্যাশলিটিক্স এসডিকে ভি১৮.৬.০+ (অথবা Firebase BoM ৩২.৬.০+)।

ক্র্যাশ-মুক্ত মেট্রিক্স দেখতে না পাওয়া (অথবা অনির্ভরযোগ্য মেট্রিক্স দেখা)

যদি আপনি ক্র্যাশ-মুক্ত মেট্রিক্স (যেমন ক্র্যাশ-মুক্ত ব্যবহারকারী এবং সেশন) দেখতে না পান অথবা অনির্ভরযোগ্য মেট্রিক্স দেখতে পান, তাহলে নিম্নলিখিত বিষয়গুলো পরীক্ষা করুন:

নিশ্চিত করুন যে আপনি ব্যবহার করছেনক্র্যাশলিটিক্স এসডিকে ভি১৮.৬.০+ (অথবা Firebase BoM ৩২.৬.০+)।
নিশ্চিত করুন যে আপনার ডেটা সংগ্রহের সেটিংস আপনার ক্র্যাশ-মুক্ত মেট্রিক্সের গুণমানকে প্রভাবিত করছে না:
- আপনি যদি স্বয়ংক্রিয় ক্র্যাশ রিপোর্টিং নিষ্ক্রিয় করে অপ্ট-ইন রিপোর্টিং চালু করেন , তাহলে ক্র্যাশের তথ্য শুধুমাত্র সেইসব ব্যবহারকারীদের কাছ থেকেই Crashlytics পাঠানো যাবে, যারা স্পষ্টভাবে ডেটা সংগ্রহের জন্য সম্মতি দিয়েছেন। ফলে, ক্র্যাশ-মুক্ত মেট্রিক্সের নির্ভুলতা প্রভাবিত হবে, কারণ Crashlytics আপনার সকল ব্যবহারকারীর পরিবর্তে শুধুমাত্র এই সম্মতি দেওয়া ব্যবহারকারীদের ক্র্যাশের তথ্যই থাকবে। এর অর্থ হলো, আপনার ক্র্যাশ-মুক্ত মেট্রিক্স কম নির্ভরযোগ্য হতে পারে এবং আপনার অ্যাপের সামগ্রিক স্থিতিশীলতার কম প্রতিফলন ঘটাতে পারে।
- আপনার যদি স্বয়ংক্রিয় ডেটা সংগ্রহ নিষ্ক্রিয় করা থাকে, তাহলে আপনি ডিভাইসে ক্যাশ করা রিপোর্টগুলো Crashlytics এ পাঠাতে sendUnsentReports ব্যবহার করতে পারেন। এই পদ্ধতি ব্যবহার করলে ক্র্যাশ ডেটা Crashlytics এ পাঠানো হবে, কিন্তু সেশন ডেটা পাঠানো হবে না, যার ফলে কনসোল চার্টে ক্র্যাশ-মুক্ত মেট্রিকগুলোর মান কম বা শূন্য দেখায়।

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

ক্র্যাশ-মুক্ত মেট্রিক্স বুঝুন দেখুন।

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

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

যখন কোনো প্রজেক্ট সদস্য একটি নোট পোস্ট করেন, তখন সেটিতে তার গুগল অ্যাকাউন্টের ইমেলটি যুক্ত করা হয়। নোটটি দেখার অ্যাক্সেস আছে এমন সকল প্রজেক্ট সদস্য নোটটির সাথে এই ইমেল ঠিকানাটিও দেখতে পান।

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

নিম্নলিখিত ভূমিকাগুলির যেকোনো একটি থাকা প্রকল্পের সদস্যরা একটি ইস্যুতে বিদ্যমান নোট দেখতে ও মুছে ফেলতে এবং নতুন নোট লিখতে পারেন।
- প্রজেক্ট ওনার বা এডিটর , ফায়ারবেস অ্যাডমিন , কোয়ালিটি অ্যাডমিন , অথবা ক্র্যাশলিটিক্স অ্যাডমিন
নিম্নলিখিত ভূমিকাগুলির যেকোনো একটি থাকা প্রকল্পের সদস্যরা একটি ইস্যুতে পোস্ট করা নোটগুলি দেখতে পারেন, কিন্তু তারা কোনো নোট মুছতে বা লিখতে পারেন না।
- প্রজেক্ট ভিউয়ার , ফায়ারবেস ভিউয়ার , কোয়ালিটি ভিউয়ার বা ক্র্যাশলিটিক্স ভিউয়ার

রিগ্রেসড ইস্যু বলতে কী বোঝায়?

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

এখানে একটি উদাহরণমূলক পরিস্থিতি দেওয়া হলো যা ব্যাখ্যা করে, Crashlytics কীভাবে একটি ইস্যুকে রিগ্রেশন হিসেবে শ্রেণীবদ্ধ করে:

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

দ্রষ্টব্য: ২০২২ সালের ফেব্রুয়ারী মাসের আগে, Crashlytics কোনো একটি সমস্যাকে রিগ্রেশন হিসেবে চিহ্নিত করত যখন সেটি অ্যাপের যেকোনো সংস্করণে পুনরায় দেখা দিত, এমনকি সেইসব অ্যাপ সংস্করণের ক্ষেত্রেও যেগুলো সম্পর্কে আপনি সমস্যাটি বন্ধ করার সময় আমাদের জানা ছিল। এর ফলে Crashlytics মাঝে মাঝে রিগ্রেশনগুলোকে ভুলভাবে শনাক্ত করত। আমরা এখন উপরে বর্ণিত নিয়মটি ব্যবহার করি।

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

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

যদি কোনো রিপোর্ট এমন একটি পুরোনো অ্যাপ ভার্সন থেকে আসে যা আপনি ইস্যুটি বন্ধ করার সময় কখনোই কোনো ক্র্যাশ রিপোর্ট পাঠায়নি, তাহলে Crashlytics ইস্যুটিকে রিগ্রেসড (পুনরায় উন্নত) বলে বিবেচনা করবে এবং ইস্যুটি পুনরায় খুলে দেবে।

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

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

দ্রষ্টব্য: ২০২২ সালের ফেব্রুয়ারী মাসের আগে, Crashlytics কোনো একটি সমস্যাকে রিগ্রেশন হিসেবে চিহ্নিত করত যখন সেটি অ্যাপের যেকোনো সংস্করণে পুনরায় দেখা দিত, এমনকি সেইসব অ্যাপ সংস্করণের ক্ষেত্রেও যেগুলো সম্পর্কে আপনি সমস্যাটি বন্ধ করার সময় আমাদের জানা ছিল। এর ফলে Crashlytics মাঝে মাঝে রিগ্রেশনগুলোকে ভুলভাবে শনাক্ত করত। আমরা এখন উপরে বর্ণিত নিয়মটি ব্যবহার করি।

যদি আপনি ২০২২ সালের ফেব্রুয়ারির আগে থেকে অনেকগুলো ভুলভাবে চিহ্নিত রিগ্রেশন দেখতে পান, তাহলে সেগুলোকে পুনরায় চালু হওয়া থেকে আটকাতে আপনি আবার বন্ধ করে দিতে পারেন।

প্ল্যাটফর্ম-নির্দিষ্ট সমর্থন

নিম্নলিখিত বিভাগগুলিতে প্ল্যাটফর্ম-ভিত্তিক সমস্যা সমাধান এবং প্রায়শই জিজ্ঞাসিত প্রশ্নাবলীর (FAQ) জন্য সহায়তা প্রদান করা হয়েছে: iOS+ | Android | Unity ।

অ্যাপল প্ল্যাটফর্ম সমর্থন

dSYM গুলি অনুপস্থিত/আপলোড হচ্ছে না

আপনার প্রোজেক্টের dSYM-গুলো আপলোড করতে এবং বিস্তারিত আউটপুট পেতে, নিম্নলিখিত বিষয়গুলো পরীক্ষা করুন:

নিশ্চিত করুন যে আপনার প্রোজেক্টের বিল্ড ফেজে Crashlytics রান স্ক্রিপ্টটি রয়েছে, যা Xcode-কে বিল্ডের সময় আপনার প্রোজেক্টের dSYM-গুলো আপলোড করার সুযোগ দেয় (স্ক্রিপ্টটি যোগ করার নির্দেশাবলীর জন্য ‘Initializing Crashlytics পড়ুন)। আপনার প্রোজেক্ট আপডেট করার পর, একটি ক্র্যাশ ঘটান এবং নিশ্চিত করুন যে ক্র্যাশটি Crashlytics ড্যাশবোর্ডে দেখা যাচ্ছে।
আপনি যদি Firebase কনসোলে "Missing dSYM" অ্যালার্ট দেখতে পান, তাহলে Xcode চেক করে নিশ্চিত হন যে এটি বিল্ডের জন্য সঠিকভাবে dSYM তৈরি করছে ।
যদি Xcode সঠিকভাবে dSYM তৈরি করে, এবং তারপরেও আপনি দেখেন যে dSYM অনুপস্থিত, তাহলে সম্ভবত রান স্ক্রিপ্ট টুলটি dSYM আপলোড করার সময় আটকে যাচ্ছে। এই ক্ষেত্রে, নিচের প্রতিটি পদ্ধতি চেষ্টা করে দেখুন:
- নিশ্চিত করুন যে আপনি Crashlytics এর সর্বশেষ সংস্করণটি ব্যবহার করছেন।
- অনুপস্থিত dSYM ফাইলগুলো ম্যানুয়ালি আপলোড করুন:
  - বিকল্প ১: অনুপস্থিত dSYM ফাইলগুলো সম্বলিত একটি জিপ আর্কাইভ আপলোড করতে dSYMs ট্যাবে থাকা কনসোল-ভিত্তিক 'ড্র্যাগ অ্যান্ড ড্রপ' বিকল্পটি ব্যবহার করুন।
  - বিকল্প ২: dSYMs ট্যাবে প্রদত্ত UUID-গুলোর জন্য অনুপস্থিত dSYM ফাইলগুলো আপলোড করতে upload-symbols স্ক্রিপ্টটি ব্যবহার করুন।
যদি আপনি ক্রমাগত dSYM অনুপস্থিত দেখতে পান, অথবা আপলোড এখনও অসফল হয়, তাহলে Firebase Support-এর সাথে যোগাযোগ করুন এবং আপনার লগগুলি অবশ্যই সংযুক্ত করুন।

দুর্ঘটনাগুলো সঠিকভাবে প্রতীকায়িত করা হয়নি।

আপনার স্ট্যাক ট্রেসগুলো যদি সঠিকভাবে প্রতীকায়িত না বলে মনে হয়, তাহলে নিম্নলিখিত বিষয়গুলো পরীক্ষা করুন:

যদি আপনার অ্যাপের লাইব্রেরির ফ্রেমগুলিতে আপনার অ্যাপের কোডের রেফারেন্স না থাকে, তাহলে নিশ্চিত করুন যে -fomit-frame-pointer কম্পাইলেশন ফ্ল্যাগ হিসেবে সেট করা নেই।
আপনার অ্যাপের লাইব্রেরিতে যদি একাধিক (Missing) ফ্রেম দেখতে পান, তাহলে Firebase কনসোলের Crashlytics dSYMs ট্যাবে পরীক্ষা করে দেখুন যে (প্রভাবিত অ্যাপ সংস্করণটির জন্য) কোনো ঐচ্ছিক dSYM অনুপস্থিত হিসেবে তালিকাভুক্ত আছে কিনা। যদি থাকে, তাহলে এই পৃষ্ঠার "dSYM অনুপস্থিত/আপলোড হচ্ছে না" সম্পর্কিত FAQ- তে থাকা "Missing dSYM alert" ট্রাবলশুটিং ধাপটি অনুসরণ করুন। মনে রাখবেন যে এই dSYM-গুলো আপলোড করলে ইতিমধ্যে ঘটে যাওয়া ক্র্যাশগুলো সিম্বোলিকেট হবে না, তবে এটি ভবিষ্যতের ক্র্যাশগুলোর জন্য সিম্বোলাইজেশন নিশ্চিত করতে সাহায্য করবে।

আমি কি macOS বা tvOS-এর জন্য Crashlytics ব্যবহার করতে পারি?

হ্যাঁ, আপনি macOS এবং tvOS প্রজেক্টে Crashlytics প্রয়োগ করতে পারেন। Google Analytics এর জন্য Firebase SDK-এর v8.9.0+ সংস্করণটি অন্তর্ভুক্ত করতে ভুলবেন না, যাতে ক্র্যাশগুলো Google Analytics দ্বারা সংগৃহীত মেট্রিকগুলো (ক্র্যাশ-মুক্ত ব্যবহারকারী, সর্বশেষ রিলিজ, ভেলোসিটি অ্যালার্ট এবং ব্রেডক্রাম্ব লগ) অ্যাক্সেস করতে পারে।

আমি কি বিভিন্ন অ্যাপল প্ল্যাটফর্মে থাকা একাধিক অ্যাপ সহ একটি ফায়ারবেস প্রকল্পে Crashlytics ব্যবহার করতে পারি?

এখন আপনি একটিমাত্র Firebase প্রজেক্টের একাধিক অ্যাপের ক্র্যাশ রিপোর্ট করতে পারবেন, এমনকি যদি অ্যাপগুলো বিভিন্ন Apple প্ল্যাটফর্মের (যেমন, iOS, tvOS, এবং Mac Catalyst) জন্য বিল্ড করা হয়ে থাকে। পূর্বে, অ্যাপগুলোতে একই বান্ডেল আইডি থাকলে সেগুলোকে আলাদা আলাদা Firebase প্রজেক্টে বিভক্ত করতে হতো।

অ্যান্ড্রয়েড সমর্থন

কেন শুধু অ্যান্ড্রয়েড ১১+ এর জন্যই এএনআর রিপোর্ট করা হচ্ছে?

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

কিছু ANR-এর `BuildId` কেন অনুপস্থিত?

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

নিশ্চিত করুন যে আপনি একটি হালনাগাদ Crashlytics Android SDK এবং Crashlytics Gradle প্লাগইন সংস্করণ ব্যবহার করছেন।
যদি আপনার অ্যান্ড্রয়েড ১১ এবং কিছু অ্যান্ড্রয়েড ১২ ANR-এর জন্য BuildId অনুপস্থিত থাকে, তাহলে সম্ভবত আপনি একটি পুরোনো SDK, Gradle প্লাগইন, অথবা উভয়ই ব্যবহার করছেন। এই ANR-গুলোর জন্য সঠিকভাবে BuildId সংগ্রহ করতে, আপনাকে নিম্নলিখিত সংস্করণগুলো ব্যবহার করতে হবে:
- Crashlytics অ্যান্ড্রয়েড এসডিকে ভি১৮.৩.৫+ ( Firebase BoM ভি৩১.২.২+)
- Crashlytics গ্রেডল প্লাগইন v2.9.4+
আপনার শেয়ার করা লাইব্রেরিগুলোর জন্য আপনি কোনো অপ্রচলিত অবস্থান ব্যবহার করছেন কিনা তা যাচাই করুন।
আপনার অ্যাপের শেয়ার্ড লাইব্রেরিগুলোর শুধু BuildId অনুপস্থিত থাকলে, সম্ভবত আপনি শেয়ার্ড লাইব্রেরির জন্য স্ট্যান্ডার্ড বা ডিফল্ট লোকেশন ব্যবহার করছেন না। যদি এমনটা হয়, তাহলে Crashlytics সংশ্লিষ্ট BuildId গুলো খুঁজে নাও পেতে পারে। আমরা আপনাকে শেয়ার্ড লাইব্রেরির জন্য স্ট্যান্ডার্ড লোকেশন ব্যবহার করার পরামর্শ দিচ্ছি।
বিল্ড প্রক্রিয়া চলাকালীন আপনি যেন BuildId গুলো মুছে না ফেলেন, তা নিশ্চিত করুন।
মনে রাখবেন যে নিম্নলিখিত সমস্যা সমাধানের টিপসগুলি ANR এবং নেটিভ ক্র্যাশ উভয়ের ক্ষেত্রেই প্রযোজ্য।
- আপনার বাইনারিগুলোতে readelf -n চালিয়ে ` BuildId গুলো আছে কিনা তা পরীক্ষা করুন। যদি ` BuildId গুলো অনুপস্থিত থাকে, তাহলে আপনার বিল্ড সিস্টেমের ফ্ল্যাগগুলোতে -Wl,--build-id যোগ করুন।
- যাচাই করে দেখুন যে আপনি আপনার APK-এর আকার কমানোর চেষ্টায় অনিচ্ছাকৃতভাবে BuildId গুলো বাদ দিয়ে দিচ্ছেন না।
- যদি আপনি কোনো লাইব্রেরির স্ট্রিপড এবং আনস্ট্রিপড সংস্করণ রাখেন, তাহলে আপনার কোডে সঠিক সংস্করণটি নির্দেশ করা নিশ্চিত করুন।

Crashlytics ড্যাশবোর্ড এবং গুগল প্লে কনসোলে ANR রিপোর্টের মধ্যে পার্থক্য

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

এছাড়াও, Crashlytics শুধুমাত্র অ্যান্ড্রয়েড ১১ বা তার পরবর্তী সংস্করণ চালিত ডিভাইসে ঘটা এএনআর (ANR) প্রদর্শন করে, যেখানে গুগল প্লে সেইসব ডিভাইসের এএনআর প্রদর্শন করে যেগুলিতে গুগল প্লে পরিষেবা চালু আছে এবং ডেটা সংগ্রহের সম্মতি দেওয়া হয়েছে।

কেন আমি `.kt` ফাইল থেকে হওয়া ক্র্যাশগুলোকে `.java` সমস্যা হিসেবে চিহ্নিত হতে দেখি?

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

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

অ্যান্ড্রয়েড গ্রেডল ৪.২.০ বা উচ্চতর সংস্করণ ব্যবহার করে।
অবফাসকেশন চালু থাকা অবস্থায় R8 ব্যবহার করা হয়েছে। আপনার অ্যাপটিকে R8-এ আপডেট করতে, এই ডকুমেন্টেশনটি অনুসরণ করুন।

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

আমি কেন এমন `.kt` ইস্যু দেখতে পাই যা বিদ্যমান `.java` ইস্যুগুলোরই সদৃশ?

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

সম্প্রতি পর্যন্ত, উপলব্ধ অবফাসকেটরগুলো ফাইল এক্সটেনশন প্রকাশ করত না, তাই Crashlytics ডিফল্টরূপে প্রতিটি ইস্যু .java ফাইল এক্সটেনশন দিয়ে তৈরি করত। তবে, অ্যান্ড্রয়েড গ্রেডল ৪.২.০ থেকে, R8 ফাইল এক্সটেনশন সমর্থন করে।

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

আপনার অ্যাপটি অ্যান্ড্রয়েড গ্রেডল ৪.২.০ বা তার উচ্চতর সংস্করণ ব্যবহার করে।
আপনার অ্যাপটি অবফাসকেশন চালু থাকা অবস্থায় R8 ব্যবহার করে।

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

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

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

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

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

নিশ্চিত করুন যে আপনি DexGuard 8.x-এর সর্বশেষ সংস্করণটি ব্যবহার করছেন। সর্বশেষ সংস্করণে এমন সব নিয়ম রয়েছে যা Firebase Crashlytics SDK-এর জন্য প্রয়োজন।
আপনি যদি আপনার DexGuard সংস্করণ পরিবর্তন করতে না চান, তাহলে আপনার অবফাসকেশন নিয়মে (আপনার DexGuard কনফিগারেশন ফাইলে) নিম্নলিখিত লাইনটি যোগ করার চেষ্টা করুন:
```
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
```

কীভাবে Crashlytics Gradle প্লাগইন v3-তে আপগ্রেড করবেন?

Crashlytics Gradle প্লাগইনের সর্বশেষ রিলিজটি একটি মেজর ভার্সন (v3.0.0) এবং এটি Gradle-এর নিম্নতর সংস্করণ ও Android Gradle প্লাগইনের সাপোর্ট বন্ধ করে SDK-টিকে আধুনিকায়ন করেছে। এছাড়াও, এই রিলিজের পরিবর্তনগুলো AGP v8.1+ এর সমস্যাগুলোর সমাধান করে এবং নেটিভ অ্যাপ ও কাস্টমাইজড বিল্ডের জন্য সাপোর্ট উন্নত করে।

ন্যূনতম প্রয়োজনীয়তা

Crashlytics Gradle প্লাগইন v3-এর নিম্নলিখিত ন্যূনতম প্রয়োজনীয়তা রয়েছে:

অ্যান্ড্রয়েড গ্রেডল প্লাগইন ৮.১+
অ্যান্ড্রয়েড স্টুডিও-র সর্বশেষ সংস্করণে অ্যান্ড্রয়েড গ্র্যাডল প্লাগইন আপগ্রেড অ্যাসিস্ট্যান্ট ব্যবহার করে এই প্লাগইনটি আপগ্রেড করুন।
ফায়ারবেসের google-services গ্রেডল প্লাগইন ৪.৪.১+
আপনার প্রোজেক্টের গ্রেডল বিল্ড ফাইলে সর্বশেষ সংস্করণটি উল্লেখ করে এই প্লাগইনটি আপগ্রেড করুন, যেমনটি নিচে দেখানো হয়েছে:

Kotlin

plugins {
  id("com.android.application") version "8.1.4" apply false
  id("com.google.gms.google-services") version "4.4.4" apply false
  ...
}

Groovy

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.4.4' apply false
  ...
}

Crashlytics এক্সটেনশনে পরিবর্তন

Crashlytics Gradle প্লাগইনের v3 সংস্করণে, Crashlytics এক্সটেনশনটিতে নিম্নলিখিত বড় ধরনের পরিবর্তনগুলো আনা হয়েছে:

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")
                }
              )
            }
          }
        }

এখন v3 তে

        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")
                }
              }
            }
          }
        }

এখন v3 তে

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }

অ্যান্ড্রয়েড-এনডিকে নির্দিষ্ট সমর্থন

Crashlytics ড্যাশবোর্ড এবং লগক্যাটে থাকা এনডিকে স্ট্যাক ট্রেসের মধ্যে পার্থক্য

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

আপনি যদি LLVM টুলচেইনের lld লিঙ্কার ব্যবহার করেন, তাহলে যোগ করুন:
```
-Wl,--no-rosegment
```
আপনি যদি GNU টুলচেইনের ld.gold লিঙ্কার ব্যবহার করেন, তাহলে যোগ করুন:
```
-Wl,--rosegment
```

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

-fno-omit-frame-pointer

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

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

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

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

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

গ্রেডল প্লাগইন v3.0.0+

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")
          }
        }
      }
   }
}

বিকল্প ২ : আপনার গ্রেডল প্রপার্টিজ ফাইলে একটি প্রপার্টি লাইনের মাধ্যমে পাথটি নির্দিষ্ট করুন।
আপনি এক্সিকিউটেবলের পাথ নির্দিষ্ট করতে com.google.firebase.crashlytics.breakpadBinary প্রপার্টিটি ব্যবহার করতে পারেন।
আপনি ম্যানুয়ালি আপনার গ্রেডল প্রপার্টিজ ফাইল আপডেট করতে পারেন অথবা কমান্ড লাইনের মাধ্যমে ফাইলটি আপডেট করতে পারেন। উদাহরণস্বরূপ, কমান্ড লাইনের মাধ্যমে পাথ নির্দিষ্ট করতে, নিম্নলিখিত কমান্ডের মতো একটি কমান্ড ব্যবহার করুন:
```
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
  -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
  app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
```

Crashlytics কি armeabi সমর্থন করে?

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

ঐক্য সমর্থন

Crashlytics ড্যাশবোর্ডে অ্যান্ড্রয়েড অ্যাপের জন্য প্রতীকবিহীন স্ট্যাক ট্রেস দেখা যাচ্ছে

আপনি যদি ইউনিটি IL2CPP ব্যবহার করেন এবং আনসিম্বলিকেটেড স্ট্যাক ট্রেস দেখতে পান, তাহলে নিম্নলিখিতগুলি চেষ্টা করুন:

নিশ্চিত করুন যে আপনি Crashlytics Unity SDK-এর v8.6.1 বা উচ্চতর সংস্করণ ব্যবহার করছেন।
আপনার সিম্বল ফাইল তৈরি ও আপলোড করার জন্য, নিশ্চিত করুন যে আপনি Firebase CLI-এর crashlytics:symbols:upload কমান্ডটি চালানোর জন্য প্রস্তুত আছেন।
প্রতিবার একটি রিলিজ বিল্ড তৈরি করার সময় অথবা এমন কোনো বিল্ডের জন্য যার সিম্বলিকেটেড স্ট্যাক ট্রেস আপনি Firebase কনসোলে দেখতে চান, আপনাকে এই CLI কমান্ডটি চালাতে হবে। ‘পঠ্যযোগ্য ক্র্যাশ রিপোর্ট পান’ অংশে আরও জানুন।

যেসব অ্যাপ IL2CPP ব্যবহার করে, সেগুলোর সাথে কি Crashlytics ব্যবহার করা যায়?

হ্যাঁ, Crashlytics আপনার IL2CPP ব্যবহারকারী অ্যাপগুলোর জন্য সিম্বলিকেটেড স্ট্যাক ট্রেস প্রদর্শন করতে পারে। এই সুবিধাটি অ্যান্ড্রয়েড বা অ্যাপল প্ল্যাটফর্মে প্রকাশিত অ্যাপগুলোর জন্য উপলব্ধ। এর জন্য আপনাকে যা করতে হবে তা হলো:

নিশ্চিত করুন যে আপনি Crashlytics Unity SDK-এর v8.6.0 বা তার উচ্চতর সংস্করণ ব্যবহার করছেন।
আপনার প্ল্যাটফর্মের জন্য প্রয়োজনীয় কাজগুলো সম্পন্ন করুন:
- অ্যাপল প্ল্যাটফর্ম অ্যাপের জন্য : কোনো বিশেষ পদক্ষেপের প্রয়োজন নেই। অ্যাপল প্ল্যাটফর্ম অ্যাপের ক্ষেত্রে, Firebase Unity Editor প্লাগইনটি সিম্বল আপলোড করার জন্য আপনার Xcode প্রজেক্টকে স্বয়ংক্রিয়ভাবে কনফিগার করে দেয়।
- অ্যান্ড্রয়েড অ্যাপের জন্য : আপনার সিম্বল ফাইল তৈরি ও আপলোড করার জন্য, নিশ্চিত করুন যে আপনি Firebase CLI-এর crashlytics:symbols:upload কমান্ডটি চালানোর জন্য প্রস্তুত আছেন।
  প্রতিবার একটি রিলিজ বিল্ড তৈরি করার সময় অথবা এমন কোনো বিল্ডের জন্য যার সিম্বলিকেটেড স্ট্যাক ট্রেস আপনি Firebase কনসোলে দেখতে চান, আপনাকে এই CLI কমান্ডটি চালাতে হবে। ‘পঠ্যযোগ্য ক্র্যাশ রিপোর্ট পান’ অংশে আরও জানুন।

অনাহূত ব্যতিক্রমগুলোকে মারাত্মক ত্রুটি হিসেবে রিপোর্ট করা

Crashlytics আনক্যাচড এক্সেপশনগুলোকে ফেটাল হিসেবে রিপোর্ট করতে পারে (Unity SDK-এর v10.4.0 থেকে শুরু করে)। নিম্নলিখিত প্রশ্নোত্তরগুলো এই ফিচারটি ব্যবহারের পেছনের যুক্তি এবং সর্বোত্তম অনুশীলন ব্যাখ্যা করতে সাহায্য করে।

একটি অ্যাপ কেন আনক্যাচড এক্সেপশনকে ফেটাল হিসেবে রিপোর্ট করবে?

আনক্যাচড এক্সেপশনগুলোকে ফেটাল হিসেবে রিপোর্ট করার মাধ্যমে, কোন কোন এক্সেপশনের কারণে গেমটি খেলার অযোগ্য হয়ে যেতে পারে, সে সম্পর্কে আরও বাস্তবসম্মত ধারণা পাওয়া যায় – এমনকি অ্যাপটি চলতে থাকলেও।

মনে রাখবেন যে, আপনি যদি মারাত্মক দুর্ঘটনাগুলো রিপোর্ট করা শুরু করেন, তাহলে আপনার ক্র্যাশ-মুক্ত ব্যবহারকারীর (CFU) শতাংশ সম্ভবত কমে যাবে, কিন্তু এই CFU মেট্রিকটি আপনার অ্যাপের সাথে শেষ ব্যবহারকারীদের অভিজ্ঞতার আরও বেশি প্রতিনিধিত্ব করবে।

কোন ব্যতিক্রমগুলোকে মারাত্মক হিসেবে রিপোর্ট করা হবে?

Crashlytics দ্বারা কোনো আনক্যাচড এক্সেপশনকে ফেটাল হিসেবে রিপোর্ট করার জন্য, নিম্নলিখিত দুটি শর্তই পূরণ হতে হবে:

আপনার অ্যাপ চালু করার সময়, ReportUncaughtExceptionsAsFatal প্রপার্টিটি অবশ্যই true তে সেট করতে হবে ।
আপনার অ্যাপ (বা কোনো অন্তর্ভুক্ত লাইব্রেরি) এমন একটি এক্সেপশন থ্রো করে যা ক্যাচ করা হয় না। যে এক্সেপশন তৈরি হয়, কিন্তু থ্রো করা হয় না , তাকে আনক্যাচড (uncaught) হিসেবে গণ্য করা হয় না।

আনক্যাচড এক্সেপশনগুলোকে ফেটাল হিসেবে রিপোর্ট করা চালু করার পর, আমি এখন অনেক নতুন ফেটাল এক্সেপশন পাচ্ছি। আমি কীভাবে এই এক্সেপশনগুলো সঠিকভাবে হ্যান্ডেল করব?

যখন আপনি আপনার আনক্যাচড এক্সেপশনগুলোকে ফেটাল হিসেবে রিপোর্ট পেতে শুরু করেন, তখন এই আনক্যাচড এক্সেপশনগুলো হ্যান্ডেল করার জন্য এখানে কিছু উপায় দেওয়া হলো:

এই আনক্যাচড এক্সেপশনগুলো কীভাবে ধরা এবং হ্যান্ডেল করা শুরু করতে পারেন, তা বিবেচনা করুন।
ইউনিটি ডিবাগ কনসোল এবং Crashlytics এক্সেপশন লগ করার জন্য বিভিন্ন বিকল্প বিবেচনা করুন।

থ্রো করা এক্সেপশনগুলো ক্যাচ এবং হ্যান্ডেল করুন

অপ্রত্যাশিত বা ব্যতিক্রমী অবস্থা বোঝাতে এক্সেপশন তৈরি ও থ্রো করা হয়। থ্রো করা এক্সেপশনের মাধ্যমে প্রতিফলিত সমস্যাগুলোর সমাধান করতে প্রোগ্রামটিকে একটি পরিচিত অবস্থায় ফিরিয়ে আনা হয় (এই প্রক্রিয়াটি এক্সেপশন হ্যান্ডলিং নামে পরিচিত)।

প্রোগ্রামটিকে কোনো জ্ঞাত অবস্থায় ফিরিয়ে আনা সম্ভব না হলে, পূর্বানুমানযোগ্য সমস্ত ব্যতিক্রম শনাক্ত করে তার সমাধান করাই উত্তম পন্থা।

কোন ধরণের এক্সেপশন কোন কোড দ্বারা ধরা ও হ্যান্ডেল করা হবে তা নিয়ন্ত্রণ করতে, যে কোড এক্সেপশন তৈরি করতে পারে তাকে একটি try-catch ব্লকের মধ্যে রাখুন । নিশ্চিত করুন যে catch স্টেটমেন্টের শর্তগুলো যতটা সম্ভব সুনির্দিষ্ট হয়, যাতে নির্দিষ্ট এক্সেপশনগুলোকে যথাযথভাবে হ্যান্ডেল করা যায়।

ইউনিটি বা Crashlytics ব্যতিক্রমগুলি লগ করুন

সমস্যাটি ডিবাগ করতে সাহায্য করার জন্য ইউনিটি বা Crashlytics এক্সেপশন রেকর্ড করার একাধিক উপায় রয়েছে।

Crashlytics ব্যবহার করার ক্ষেত্রে, সবচেয়ে প্রচলিত ও প্রস্তাবিত দুটি বিকল্প হলো:

বিকল্প ১: ইউনিটি কনসোলে প্রিন্ট করুন, কিন্তু ডেভেলপমেন্ট বা ট্রাবলশুটিং চলাকালীন Crashlytics রিপোর্ট করবেন না।
- Debug.Log(exception) , Debug.LogWarning(exception) , এবং Debug.LogError(exception) ব্যবহার করে ইউনিটি কনসোলে প্রিন্ট করুন, যেগুলো এক্সেপশনের বিষয়বস্তু ইউনিটি কনসোলে প্রিন্ট করে এবং এক্সেপশনটি পুনরায় থ্রো করে না।
বিকল্প ২: নিম্নলিখিত পরিস্থিতিগুলির জন্য Crashlytics ড্যাশবোর্ডে সমন্বিত রিপোর্টিং পেতে Crashlytics আপলোড করুন:
- যদি পরবর্তী কোনো সম্ভাব্য Crashlytics ইভেন্ট ডিবাগ করার জন্য কোনো এক্সেপশন লগ করার প্রয়োজন হয়, তাহলে Crashlytics.Log(exception.ToString()) ব্যবহার করুন।
- যদি কোনো এক্সেপশন ধরা এবং হ্যান্ডেল করার পরেও Crashlytics এ রিপোর্ট করার প্রয়োজন হয়, তাহলে সেটিকে একটি নন-ফেটাল ইভেন্ট হিসেবে লগ করতে Crashlytics.LogException(exception) ব্যবহার করুন।

তবে, আপনি যদি ইউনিটি ক্লাউড ডায়াগনস্টিকস-এ ম্যানুয়ালি কোনো মারাত্মক ঘটনা রিপোর্ট করতে চান, তাহলে আপনি Debug.LogException ব্যবহার করতে পারেন। এই বিকল্পটি অপশন ১-এর মতোই ইউনিটি কনসোলে এক্সেপশনটি প্রিন্ট করে, কিন্তু এটি এক্সেপশনটি থ্রোও করে (সেটি থ্রো বা ক্যাচ করা হয়েছে কি না, তা নির্বিশেষে)। এটি এররটি ননলোকালি থ্রো করে। এর মানে হলো, try-catch ব্লক দিয়ে Debug.LogException(exception) কে ঘিরে রাখলেও এর ফলে একটি আনক্যাচড এক্সেপশন তৈরি হয়।

সুতরাং, শুধুমাত্র তখনই Debug.LogException কল করুন, যদি আপনি নিম্নলিখিত সবগুলি কাজ করতে চান:

ইউনিটি কনসোলে এক্সেপশনটি প্রিন্ট করতে।
ব্যতিক্রমটিকে একটি মারাত্মক ঘটনা হিসেবে Crashlytics আপলোড করতে।
এক্সেপশনটি থ্রো করতে, এটিকে একটি আনক্যাচড এক্সেপশন হিসেবে গণ্য করতে এবং ইউনিটি ক্লাউড ডায়াগনস্টিকসে রিপোর্ট করতে হবে।

মনে রাখবেন, যদি আপনি ধরা পড়া কোনো এক্সেপশন ইউনিটি কনসোলে প্রিন্ট করতে এবং 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
    //
}

ইন্টিগ্রেশন সমর্থন

অ্যাপটি Google Mobile Ads এসডিকে ব্যবহার করলেও ক্র্যাশ হচ্ছে না।

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

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

BigQuery তে ডেটা এক্সপোর্ট সেট আপ করার সময় আপনি যে ডেটাসেট লোকেশনটি নির্বাচন করেছিলেন, Firebase সেখানেই ডেটা এক্সপোর্ট করে।

এই অবস্থানটি Crashlytics ডেটাসেট এবং Firebase সেশন ডেটাসেট (যদি সেশন ডেটা এক্সপোর্টের জন্য সক্ষম করা থাকে) উভয়ের ক্ষেত্রেই প্রযোজ্য।
এই অবস্থানটি শুধুমাত্র BigQuery তে এক্সপোর্ট করা ডেটার জন্য প্রযোজ্য এবং এটি Firebase কনসোলের Crashlytics ড্যাশবোর্ডে বা Android Studio-তে ব্যবহারের জন্য সংরক্ষিত ডেটার অবস্থানকে প্রভাবিত করে না।
একটি ডেটাসেট তৈরি করার পরে, এর অবস্থান পরিবর্তন করা যায় না, তবে আপনি ডেটাসেটটি অন্য কোনো স্থানে কপি করতে পারেন অথবা ম্যানুয়ালি অন্য কোনো স্থানে সরিয়ে (পুনরায় তৈরি) করতে পারেন। আরও জানতে, "বিদ্যমান এক্সপোর্টগুলির অবস্থান পরিবর্তন করুন" দেখুন।

BigQuery এর নতুন এক্সপোর্ট পরিকাঠামোতে আপগ্রেড করার পর কোনো সমস্যা হচ্ছে কি?

২০২৪ সালের অক্টোবরের মাঝামাঝি সময়ে, Crashlytics Crashlytics ডেটা BigQuery তে ব্যাচ আকারে রপ্তানি করার জন্য একটি নতুন পরিকাঠামো চালু করেছে।

২ মার্চ, ২০২৬ থেকে সকল ফায়ারবেস প্রোজেক্ট স্বয়ংক্রিয়ভাবে নতুন ব্যাচ এক্সপোর্ট পরিকাঠামোতে আপগ্রেড করা হয়েছে।

পুরাতন রপ্তানি পরিকাঠামো এবং নতুন রপ্তানি পরিকাঠামোর মধ্যে গুরুত্বপূর্ণ পার্থক্য

নতুন পরিকাঠামোটি মার্কিন যুক্তরাষ্ট্রের বাইরের Crashlytics ডেটাসেট অবস্থানগুলিকে সমর্থন করে।
- ২০২৪ সালের অক্টোবরের মাঝামাঝি সময়ের আগে এক্সপোর্ট চালু করা হয়েছে এবং নতুন এক্সপোর্ট পরিকাঠামোতে আপগ্রেড করা হয়েছে — আপনি এখন ঐচ্ছিকভাবে ডেটা এক্সপোর্টের স্থান পরিবর্তন করতে পারবেন।
- ২০২৪ সালের অক্টোবরের মাঝামাঝি বা তার পরে এক্সপোর্ট সক্রিয় করা হয়েছে — সেটআপের সময় আপনাকে ডেটা এক্সপোর্টের জন্য একটি স্থান নির্বাচন করতে বলা হয়েছিল।
নতুন পরিকাঠামোটি আপনার এক্সপোর্ট সক্ষম করার আগের ডেটা ব্যাকফিল করা সমর্থন করে না।
- পুরানো পরিকাঠামোটি আপনার এক্সপোর্ট সক্ষম করার তারিখের ৩০ দিন পূর্ব পর্যন্ত ব্যাকফিল সমর্থন করত।
- নতুন পরিকাঠামোটি বিগত ৩০ দিন পর্যন্ত অথবা BigQuery তে এক্সপোর্ট সক্ষম করার সর্বশেষ তারিখ পর্যন্ত (দুটির মধ্যে যেটি সর্বশেষ) ব্যাকফিল সমর্থন করে।
নতুন পরিকাঠামোটি আপনার Firebase প্রজেক্টে থাকা Firebase অ্যাপগুলোর জন্য সেট করা আইডেন্টিফায়ার ব্যবহার করে BigQuery ব্যাচ টেবিলগুলোর নামকরণ করে।
- পুরানো পরিকাঠামোটি আপনার অ্যাপের বাইনারিতে থাকা বান্ডেল আইডি বা প্যাকেজ নামের উপর ভিত্তি করে ব্যাচ টেবিলগুলিতে ডেটা লিখত।
- নতুন পরিকাঠামোটি আপনার Firebase প্রোজেক্টে নিবন্ধিত Firebase অ্যাপগুলির জন্য সেট করা বান্ডেল আইডি বা প্যাকেজ নামের উপর ভিত্তি করে ব্যাচ টেবিলগুলিতে ডেটা লেখে।

যদি আপনার লিগ্যাসি ব্যাচ টেবিলের নামটি আপনার ফায়ারবেস অ্যাপ আইডেন্টিফায়ারের সাথে না মেলে

যদি আপনার পুরোনো ব্যাচ টেবিলের নামটি আপনার নিবন্ধিত Firebase অ্যাপের জন্য সেট করা বান্ডেল আইডি বা প্যাকেজ নামের সাথে না মেলে, তাহলে আপনার এক্সপোর্ট করা ব্যাচ ডেটাতে আরও ব্যাঘাত এড়াতে এই বিকল্পগুলির মধ্যে একটি প্রয়োগ করুন।

BigQuery টেবিলে ডেটা লেখার জন্য এক্সপোর্ট পরিকাঠামো কীভাবে আইডেন্টিফায়ার ব্যবহার করে তা বুঝুন।

যেভাবে দুটি এক্সপোর্ট ইনফ্রাস্ট্রাকচার Crashlytics ডেটা BigQuery ব্যাচ টেবিলে লেখে, তা নিচে দেওয়া হলো:

লিগ্যাসি এক্সপোর্ট ইনফ্রাস্ট্রাকচার : আপনার অ্যাপের বাইনারিতে থাকা বান্ডেল আইডি বা প্যাকেজ নামের উপর ভিত্তি করে একটি নামের টেবিলে ডেটা লেখা হয়েছে।
নতুন এক্সপোর্ট পরিকাঠামো : আপনার Firebase প্রজেক্টে নিবন্ধিত Firebase অ্যাপের জন্য সেট করা বান্ডেল আইডি বা প্যাকেজ নামের উপর ভিত্তি করে একটি নামের টেবিলে ডেটা লেখে।

দুর্ভাগ্যবশত, কখনও কখনও আপনার অ্যাপের বাইনারিতে থাকা বান্ডেল আইডি বা প্যাকেজ নেম , আপনার ফায়ারবেস প্রজেক্টে রেজিস্টার করা ফায়ারবেস অ্যাপের জন্য সেট করা বান্ডেল আইডি বা প্যাকেজ নেমের সাথে মেলে না। সাধারণত অ্যাপ রেজিস্ট্রেশনের সময় কেউ সঠিক আইডেন্টিফায়ারটি প্রবেশ না করলে এমনটা হয়ে থাকে।

আপগ্রেড করার আগে যদি এটি ঠিক করা না হয়, তাহলে কী হবে?

যদি এই দুটি স্থানের আইডেন্টিফায়ারগুলো না মেলে, তাহলে নিম্নলিখিত ঘটনাটি ঘটেছে:

আপনার Crashlytics ডেটা এখন একটি নতুন BigQuery ব্যাচ টেবিলে লেখা হয় — অর্থাৎ, এটি এমন একটি নতুন টেবিল যার নামটি আপনার Firebase প্রজেক্টে নিবন্ধিত Firebase অ্যাপের জন্য সেট করা বান্ডেল আইডি বা প্যাকেজ নামের উপর ভিত্তি করে রাখা হয়।
আপনার অ্যাপের বাইনারিতে থাকা আইডেন্টিফায়ারের উপর ভিত্তি করে নামযুক্ত কোনো বিদ্যমান "লেগ্যাসি" টেবিলে আর ডেটা লেখা হয় না।

অমিল শনাক্তকারীর উদাহরণ পরিস্থিতি

উল্লেখ্য যে, অ্যাপটির প্ল্যাটফর্ম বোঝানোর জন্য BigQuery ব্যাচ টেবিলের নামগুলোর শেষে স্বয়ংক্রিয়ভাবে _IOS বা _ANDROID যুক্ত হয়ে যায়।

আপনার অ্যাপের বাইনারিতে শনাক্তকারী(গুলি)	আপনার Firebase অ্যাপ(গুলি)র জন্য সেট করা শনাক্তকারী(গুলি)	উত্তরাধিকার আচরণ	আপগ্রেডের পরের আচরণ নতুন রপ্তানি পরিকাঠামোতে	সমাধান
`foo`	`bar`	অ্যাপের বাইনারিতে থাকা আইডেন্টিফায়ার ( `foo` ) অনুসারে নামাঙ্কিত একটিমাত্র টেবিলে লেখে।	ফায়ারবেস অ্যাপের ( `bar` ) জন্য সেট করা আইডেন্টিফায়ারের নামে একটি একক টেবিল তৈরি করে এবং তারপর তাতে লেখে।	নীচে বর্ণিত বিকল্প ১ অথবা ২ বাস্তবায়ন করুন।
`foo`	`bar` , `qux` , etc.	Writes to a single table named after the identifier in app's binary ( `foo` )	Creates* then writes to multiple tables named after the identifiers set for Firebase Apps ( `bar` , `qux` , etc.)	Implement Option 2 described below.
`foo` , `baz` , etc.	`bar`	Writes to multiple tables named after the multiple identifiers in app's binary ( `foo` , `baz` , etc.)	Creates** then writes every app's data to a single table named after the identifier set for Firebase App ( `bar` )	None of the options can be implemented. You can still differentiate data from each app within the single table by using the app's `bundle_identifier` which is exported alongside the data.

^{* If the identifier in your app's binary matched one of the identifiers set for a Firebase App, then the new export infrastructure didn't create a new table for that identifier. Instead, it will continue writing data for that specific app to it. All other apps will be written to new tables.}

^{** If one of the identifiers in your app's binary matched the identifier set for the Firebase App, then the new export infrastructure didn't create a new table. Instead, it will maintain that table and start writing data for all apps to it.}

Options to mitigate disruption

OPTION 1 :
Use the new table created by the new export infrastructure. You'll copy data from your legacy table to the new table.
1. In the Google Cloud console, copy all the data from your legacy table to the new table that was created during the infrastructure upgrade.
2. If you have any downstream dependencies that depend on your batch table, change them to use the new table.
Note: New data will not write to your legacy table. Any previously written data in the legacy table won't be deleted.
OPTION 2 :
Reconfigure to write to your legacy table again. You'll need to override some defaults in a BigQuery config to achieve this.
1. In the Firebase console, find and take note of the Firebase App ID (for example, 1:1234567890:ios:321abc456def7890 ) of the app with the mismatched batch table name and identifier:
  Go to your Project settings , then go the Your apps card to see all your Firebase Apps and their information.
2. In the Google Cloud console, change the new "data transfer config" that was created by the infrastructure upgrade so that data will write to your legacy table:
  1. Go to BigQuery > Data transfers to view your "data transfer config".
  2. Select the config that has the source Firebase Crashlytics with Multi-Region Support .
  3. Click Edit in the top-right corner.
  4. In the Data source details section, find a list for gmp_app_id and a list for client_namespace .
    In BigQuery , the Firebase App ID is called the gmp_app_id . By default, the client_namespace value in BigQuery is the corresponding unique bundle ID / package name of the app, but you'll be overriding this default configuration.
    BigQuery uses the client_namespace value for the name of the batch table that each linked Firebase App writes to.
  5. Find the gmp_app_id of the Firebase App for which you want to override default settings. Change its client_namespace value to the name of the table you want the Firebase App to write to instead (usually this is the name of the legacy table the app was writing to with the legacy export infrastructure).
    Note: If you were previously writing to a single table and now you have multiple tables after upgrading, then you can use the same client_namespace for each applicable gmp_app_id . BigQuery will essentially merge all the tables and write all data for all the Firebase Apps to that one table.
  6. Save the config change.
3. Schedule a backfill for the days that your legacy table is missing data.
4. Once the backfill is done, delete the new table that was automatically created by the new export infrastructure.

সাধারণ সমস্যা সমাধান/প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

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

ব্রেডক্রাম্ব লগ দেখতে না পাওয়া

বেগের সতর্কতা দেখা যাচ্ছে না

ক্র্যাশ-মুক্ত মেট্রিক্স দেখতে না পাওয়া (অথবা অনির্ভরযোগ্য মেট্রিক্স দেখা)

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

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

রিগ্রেসড ইস্যু বলতে কী বোঝায়?

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

প্ল্যাটফর্ম-নির্দিষ্ট সমর্থন

অ্যাপল প্ল্যাটফর্ম সমর্থন

dSYM গুলি অনুপস্থিত/আপলোড হচ্ছে না

দুর্ঘটনাগুলো সঠিকভাবে প্রতীকায়িত করা হয়নি।

আমি কি macOS বা tvOS-এর জন্য Crashlytics ব্যবহার করতে পারি?

আমি কি বিভিন্ন অ্যাপল প্ল্যাটফর্মে থাকা একাধিক অ্যাপ সহ একটি ফায়ারবেস প্রকল্পে Crashlytics ব্যবহার করতে পারি?

অ্যান্ড্রয়েড সমর্থন

কেন শুধু অ্যান্ড্রয়েড ১১+ এর জন্যই এএনআর রিপোর্ট করা হচ্ছে?

কিছু ANR-এর BuildId কেন অনুপস্থিত?

Crashlytics ড্যাশবোর্ড এবং গুগল প্লে কনসোলে ANR রিপোর্টের মধ্যে পার্থক্য

কেন আমি .kt ফাইল থেকে হওয়া ক্র্যাশগুলোকে .java সমস্যা হিসেবে চিহ্নিত হতে দেখি?

আমি কেন এমন .kt ইস্যু দেখতে পাই যা বিদ্যমান .java ইস্যুগুলোরই সদৃশ?

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

কীভাবে Crashlytics Gradle প্লাগইন v3-তে আপগ্রেড করবেন?

ন্যূনতম প্রয়োজনীয়তা

Kotlin

Groovy

Crashlytics এক্সটেনশনে পরিবর্তন

এক্সটেনশনটি কীভাবে আপগ্রেড করবেন তার উদাহরণ

Kotlin

Groovy

অ্যান্ড্রয়েড-এনডিকে নির্দিষ্ট সমর্থন

Crashlytics ড্যাশবোর্ড এবং লগক্যাটে থাকা এনডিকে স্ট্যাক ট্রেসের মধ্যে পার্থক্য

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

গ্রেডল প্লাগইন v3.0.0+

নিম্ন প্লাগইন সংস্করণ

Crashlytics কি armeabi সমর্থন করে?

ঐক্য সমর্থন

Crashlytics ড্যাশবোর্ডে অ্যান্ড্রয়েড অ্যাপের জন্য প্রতীকবিহীন স্ট্যাক ট্রেস দেখা যাচ্ছে

যেসব অ্যাপ IL2CPP ব্যবহার করে, সেগুলোর সাথে কি Crashlytics ব্যবহার করা যায়?

অনাহূত ব্যতিক্রমগুলোকে মারাত্মক ত্রুটি হিসেবে রিপোর্ট করা

একটি অ্যাপ কেন আনক্যাচড এক্সেপশনকে ফেটাল হিসেবে রিপোর্ট করবে?

কোন ব্যতিক্রমগুলোকে মারাত্মক হিসেবে রিপোর্ট করা হবে?

থ্রো করা এক্সেপশনগুলো ক্যাচ এবং হ্যান্ডেল করুন

ইউনিটি বা Crashlytics ব্যতিক্রমগুলি লগ করুন

ইন্টিগ্রেশন সমর্থন

অ্যাপটি Google Mobile Ads এসডিকে ব্যবহার করলেও ক্র্যাশ হচ্ছে না।

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

BigQuery এর নতুন এক্সপোর্ট পরিকাঠামোতে আপগ্রেড করার পর কোনো সমস্যা হচ্ছে কি?

পুরাতন রপ্তানি পরিকাঠামো এবং নতুন রপ্তানি পরিকাঠামোর মধ্যে গুরুত্বপূর্ণ পার্থক্য

যদি আপনার লিগ্যাসি ব্যাচ টেবিলের নামটি আপনার ফায়ারবেস অ্যাপ আইডেন্টিফায়ারের সাথে না মেলে

BigQuery টেবিলে ডেটা লেখার জন্য এক্সপোর্ট পরিকাঠামো কীভাবে আইডেন্টিফায়ার ব্যবহার করে তা বুঝুন।

আপগ্রেড করার আগে যদি এটি ঠিক করা না হয়, তাহলে কী হবে?

অমিল শনাক্তকারীর উদাহরণ পরিস্থিতি

Options to mitigate disruption

কিছু ANR-এর `BuildId` কেন অনুপস্থিত?

কেন আমি `.kt` ফাইল থেকে হওয়া ক্র্যাশগুলোকে `.java` সমস্যা হিসেবে চিহ্নিত হতে দেখি?

আমি কেন এমন `.kt` ইস্যু দেখতে পাই যা বিদ্যমান `.java` ইস্যুগুলোরই সদৃশ?