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

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

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

এই পৃষ্ঠায়, আপনি নিম্নলিখিত ধরণের বিষয় সম্পর্কে তথ্য পেতে পারেন:

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

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

সমস্যা সারণীতে কিছু সমস্যার জন্য বিভিন্ন ফর্ম্যাট (এবং কখনও কখনও "ভেরিয়েন্ট") দেখা হচ্ছে

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

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

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

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

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

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

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

এই উন্নতিগুলি কীভাবে কার্যকর হচ্ছে তা এখানে দেওয়া হল:

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

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

ব্রেডক্রাম্বের কাঠ দেখা যাচ্ছে না

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

আপনি আপনার Firebase প্রকল্পে Google Analytics সক্ষম করেছেন ।
আপনি Google Analytics এর জন্য ডেটা শেয়ারিং সক্ষম করেছেন। আপনার Analytics ডেটা শেয়ারিং সেটিংস পরিচালনা করুন বিভাগে এই সেটিং সম্পর্কে আরও জানুন।
আপনি আপনার অ্যাপে Google Analytics এর জন্য Firebase SDK যোগ করেছেন: iOS+ | Android | Flutter | Unity ।
এই SDK টি Crashlytics SDK এর সাথে যুক্ত করতে হবে।
আপনার অ্যাপে ব্যবহৃত সমস্ত পণ্যের জন্য আপনি সর্বশেষ Firebase SDK সংস্করণ ব্যবহার করছেন ( iOS+ | Android | Flutter | Unity )।
অ্যাপল প্ল্যাটফর্ম এবং অ্যান্ড্রয়েড অ্যাপের জন্য, বিশেষ করে নিশ্চিত করুন যে আপনি Google Analytics এর জন্য Firebase SDK এর কমপক্ষে নিম্নলিখিত সংস্করণটি ব্যবহার করছেন: iOS+ — v6.3.1+ (macOS এবং tvOS এর জন্য v8.9.0+) | Android — v17.2.3+ ( BoM v24.7.1+)।

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

যদি আপনি বেগের সতর্কতা দেখতে না পান, তাহলে নিশ্চিত করুন যে আপনি ব্যবহার করছেন

ক্র্যাশ-মুক্ত মেট্রিক্স না দেখা (অথবা অবিশ্বস্ত মেট্রিক্স দেখা)

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

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

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

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

কে কোন বিষয়ে নোট দেখতে, লিখতে এবং মুছে ফেলতে পারে?

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

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

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

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

রিগ্রেসড ইস্যু কী?

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

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

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

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

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

পুরনো অ্যাপ ভার্সনের জন্য কেন আমি রিগ্রেসড সমস্যা দেখতে পাচ্ছি?

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

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

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

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

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

প্ল্যাটফর্ম-নির্দিষ্ট সহায়তা

নিম্নলিখিত বিভাগগুলি প্ল্যাটফর্ম-নির্দিষ্ট সমস্যা সমাধান এবং প্রায়শই জিজ্ঞাসিত প্রশ্নাবলীর জন্য সহায়তা প্রদান করে: iOS+ | অ্যান্ড্রয়েড | ইউনিটি ।

অ্যাপল প্ল্যাটফর্ম সাপোর্ট

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

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

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

ক্র্যাশগুলিকে দুর্বলভাবে প্রতীকী করা হয়েছে

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

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

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

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

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

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

অ্যান্ড্রয়েড সাপোর্ট

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

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

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

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

নিশ্চিত করুন যে আপনি একটি আপ-টু-ডেট Crashlytics Android SDK এবং Crashlytics Gradle প্লাগইন সংস্করণ ব্যবহার করছেন।
যদি আপনার Android 11 এবং কিছু Android 12 ANR-এর জন্য BuildId গুলি অনুপস্থিত থাকে, তাহলে সম্ভবত আপনি একটি পুরানো SDK, Gradle প্লাগইন, অথবা উভয়ই ব্যবহার করছেন। এই ANR-এর জন্য BuildId গুলি সঠিকভাবে সংগ্রহ করতে, আপনাকে নিম্নলিখিত সংস্করণগুলি ব্যবহার করতে হবে:
- Crashlytics অ্যান্ড্রয়েড এসডিকে v18.3.5+ ( Firebase BoM v31.2.2+)
- 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 রিপোর্ট করে, যেখানে Android Vitals ANR হওয়ার পরে ANR ডেটা পাঠায়।

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

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

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

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

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

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

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

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

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

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

আপনার অ্যাপটি Android Gradle 4.2.0 বা তার উচ্চতর সংস্করণ ব্যবহার করে।
আপনার অ্যাপটি অস্পষ্টতা চালু রেখে 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 গ্রেডল প্লাগইন 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 android ব্লক থেকে এক্সটেনশনটি সরিয়ে ফেলা হয়েছে। পরিবর্তে, আপনার প্রতিটি ভেরিয়েন্ট কনফিগার করা উচিত।
অবচিত ক্ষেত্র mappingFile সরানো হয়েছে। পরিবর্তে, মার্জ করা ম্যাপিং ফাইলটি এখন স্বয়ংক্রিয়ভাবে সরবরাহ করা হয়েছে।
অবচিত ক্ষেত্র strippedNativeLibsDir সরানো হয়েছে। পরিবর্তে, আপনার সমস্ত নেটিভ libs এর জন্য 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 ড্যাশবোর্ড এবং লগক্যাটে NDK স্ট্যাক ট্রেসের মধ্যে পার্থক্য

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

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

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

-fno-omit-frame-pointer

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

Crashlytics প্লাগইনটি একটি কাস্টমাইজড ব্রেকপ্যাড প্রতীক ফাইল জেনারেটরকে একত্রিত করে। যদি আপনি ব্রেকপ্যাড প্রতীক ফাইল তৈরির জন্য আপনার নিজস্ব বাইনারি ব্যবহার করতে চান (উদাহরণস্বরূপ, যদি আপনি আপনার বিল্ড চেইন থেকে উৎস থেকে সমস্ত নেটিভ এক্সিকিউটেবল তৈরি করতে চান), তাহলে এক্সিকিউটেবলের পথ নির্দিষ্ট করতে ঐচ্ছিক 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 প্রপার্টি ব্যবহার করতে পারেন।
আপনি আপনার Gradle প্রোপার্টি ফাইলটি ম্যানুয়ালি আপডেট করতে পারেন অথবা কমান্ড লাইনের মাধ্যমে ফাইলটি আপডেট করতে পারেন। উদাহরণস্বরূপ, কমান্ড লাইনের মাধ্যমে পাথ নির্দিষ্ট করতে, নিম্নলিখিত কমান্ডটি ব্যবহার করুন:
```
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \
  -Pcom.google.firebase.crashlytics.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
  app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
```

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

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

ঐক্য সমর্থন

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

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

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

IL2CPP ব্যবহারকারী অ্যাপগুলির সাথে কি Crashlytics ব্যবহার করা যেতে পারে?

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

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

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

Crashlytics ধরা না পড়া ব্যতিক্রমগুলিকে মারাত্মক হিসাবে রিপোর্ট করতে পারে (Unity SDK এর v10.4.0 দিয়ে শুরু)। নিম্নলিখিত FAQ গুলি এই বৈশিষ্ট্যটি ব্যবহারের যুক্তি এবং সর্বোত্তম অনুশীলনগুলি ব্যাখ্যা করতে সহায়তা করে।

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

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

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

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

Crashlytics যাতে কোনও ধরা না পড়া ব্যতিক্রমকে মারাত্মক হিসেবে রিপোর্ট করতে পারে, তার জন্য নিম্নলিখিত দুটি শর্ত অবশ্যই পূরণ করতে হবে:

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

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

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

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

থ্রো করা ব্যতিক্রমগুলি ধরুন এবং পরিচালনা করুন

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

প্রোগ্রামটিকে একটি পরিচিত অবস্থায় ফিরিয়ে আনা না গেলে, সমস্ত পূর্বাভাসিত ব্যতিক্রমগুলি ধরা এবং পরিচালনা করা সর্বোত্তম অনুশীলন।

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

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

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

Crashlytics ব্যবহার করার সময়, এখানে দুটি সবচেয়ে সাধারণ এবং প্রস্তাবিত বিকল্প রয়েছে:

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

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

অতএব, যদি আপনি নিম্নলিখিত সমস্ত কিছু করতে চান তবেই 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 SDK ব্যবহার করে কিন্তু ক্র্যাশ হচ্ছে না।

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

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

BigQuery তে ডেটা এক্সপোর্ট সেট আপ করার সময় Firebase আপনার নির্বাচিত ডেটাসেট অবস্থানে ডেটা এক্সপোর্ট করে।

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

BigQuery জন্য নতুন রপ্তানি পরিকাঠামোতে কীভাবে আপগ্রেড করবেন?

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

যদি আপনি ২০২৪ সালের অক্টোবরের পরে ব্যাচ এক্সপোর্ট সক্ষম করে থাকেন, তাহলে আপনার ফায়ারবেস প্রকল্পটি স্বয়ংক্রিয়ভাবে নতুন এক্সপোর্ট অবকাঠামো ব্যবহার করছে। কোনও পদক্ষেপ নেওয়ার প্রয়োজন নেই।
যদি আপনি ২০২৪ সালের অক্টোবরের আগে বা তার মধ্যে ব্যাচ এক্সপোর্ট সক্ষম করে থাকেন, তাহলে আপনার কোনও পদক্ষেপ নেওয়ার প্রয়োজন কিনা তা নির্ধারণ করতে এই FAQ-এর তথ্য পর্যালোচনা করুন।

৯ জানুয়ারী, ২০২৬ তারিখের মধ্যে সমস্ত Firebase প্রকল্প স্বয়ংক্রিয়ভাবে নতুন ব্যাচ এক্সপোর্ট অবকাঠামোতে আপগ্রেড করা হবে। আপনি এই তারিখের আগে আপগ্রেড করতে পারেন, তবে নিশ্চিত করুন যে আপনার BigQuery ব্যাচ টেবিলগুলি আপগ্রেড করার পূর্বশর্তগুলি পূরণ করে।

আপনি নতুন অবকাঠামোতে আপগ্রেড করতে পারেন, তবে নিশ্চিত করুন যে আপনার BigQuery ব্যাচ টেবিলগুলি আপগ্রেড করার পূর্বশর্তগুলি পূরণ করে।

আপনি নতুন অবকাঠামোতে আছেন কিনা তা নির্ধারণ করুন

যদি আপনি ২০২৪ সালের অক্টোবরের মাঝামাঝি বা তার পরে ব্যাচ এক্সপোর্ট সক্ষম করে থাকেন, তাহলে আপনার ফায়ারবেস প্রকল্পটি স্বয়ংক্রিয়ভাবে নতুন এক্সপোর্ট অবকাঠামো ব্যবহার করছে।

আপনার প্রকল্পটি কোন অবকাঠামো ব্যবহার করছে তা আপনি পরীক্ষা করতে পারেন: Google Cloud কনসোলে যান এবং যদি আপনার "ডেটা ট্রান্সফার কনফিগারেশন" লেবেলযুক্ত হয় Firebase Crashlytics with Multi-Region Support , তাহলে আপনার প্রকল্পটি নতুন রপ্তানি অবকাঠামো ব্যবহার করছে।

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

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

ধাপ ১ : আপগ্রেড করার পূর্বশর্ত

আপনার বিদ্যমান BigQuery ব্যাচ টেবিলগুলি আপনার Firebase প্রকল্পে নিবন্ধিত Firebase অ্যাপের জন্য সেট করা বান্ডেল আইডি বা প্যাকেজ নামের সাথে মিলে যাওয়া শনাক্তকারী ব্যবহার করে কিনা তা পরীক্ষা করে দেখুন। যদি সেগুলি না মেলে, তাহলে আপনার রপ্তানি করা ব্যাচ ডেটাতে ব্যাঘাত ঘটতে পারে। বেশিরভাগ প্রকল্পই সঠিক এবং সামঞ্জস্যপূর্ণ অবস্থায় থাকবে, তবে আপগ্রেড করার আগে এটি পরীক্ষা করা গুরুত্বপূর্ণ।
- You can find all the Firebase Apps registered in your Firebase project in the Firebase console: Go to your Project settings , then scroll to the Your apps card to see all your Firebase Apps and their information.
- You can find all your BigQuery batch tables in the BigQuery page of the Google Cloud console.
Note: BigQuery streaming tables that end with REALTIME aren't affected by the new export infrastructure and can be ignored.
For example, here are ideal states where you won't have any issues upgrading:
- You have a batch table named com_yourcompany_yourproject_IOS and a Firebase iOS+ App with the bundle ID com.yourcompany.yourproject registered in your Firebase project.
- You have a batch table named com_yourcompany_yourproject_ANDROID and a Firebase Android App with the package name com.yourcompany.yourproject registered in your Firebase project.
If you have batch table names that do not match the identifiers set for your registered Firebase Apps, then follow the instructions later on this page before manually upgrading or before January 9, 2026 to avoid disruption to your batch export.

Step 2 : Manually upgrade to the new infrastructure

If you enabled batch export before mid-October 2024, then you can manually upgrade to the new infrastructure simply by toggling Crashlytics data export off and then on again in the Firebase console.

Here are the detailed steps:

In the Firebase console, go to the Integrations page .
BigQuery কার্ডে, Manage এ ক্লিক করুন।
Toggle off the Crashlytics slider to disable export. When prompted, confirm that you want data export to stop.
Immediately toggle on again the Crashlytics slider to re-enable export. When prompted, confirm that you want to export data.
Your Crashlytics data export to BigQuery is now using the new export infrastructure.

Your existing batch table name doesn't match your Firebase App identifier

If your existing batch table name does not match the bundle ID or package name set for your registered Firebase App, then expand this section and implement one of the options to avoid disruptions to your exported batch data.

If you have existing BigQuery batch tables in this state, then it means that they're not compatible with Firebase's new batch export-to- BigQuery infrastructure. Note that all Firebase projects will be automatically migrated to the new export infrastructure as early as January 9, 2026.

Follow the guidance in this section before manually upgrading or before January 9, 2026 to avoid disruption to the batch export of your Crashlytics data to BigQuery .

Jump to instructions for options to avoid disruptions

Understand how the export infrastructure uses identifiers to write data to BigQuery tables

Here's how the two export infrastructures write Crashlytics data to BigQuery batch tables:

Legacy export infrastructure : Writes data to a table with a name that's based on the bundle ID or package name in your app's binary .
New export infrastructure : Writes data to a table with a name that's based on the bundle ID or package name set for your registered Firebase App in your Firebase project .

Unfortunately, sometimes the bundle ID or package name in your app's binary doesn't match the bundle ID or package name set for your registered Firebase App in your Firebase project . This usually happens if someone didn't enter the actual identifier during app registration.

What happens if this isn't fixed before upgrading?

If the identifiers in these two locations don't match, then the following happens after upgrading to the new export infrastructure:

Your Crashlytics data will start writing to a new BigQuery batch table — that is, a new table with a name based on the bundle ID or package name set for your registered Firebase App in your Firebase project .
Any existing "legacy" table with a name based on the identifier in your app's binary will no longer have data written to it.

Example scenarios of mismatched identifiers

Note that BigQuery batch table names are automatically appended with _IOS or _ANDROID to indicate the platform of the app.

Identifier(s) in your app's binary	Identifier(s) set for your Firebase App(s)	Legacy behavior	Behavior after upgrade to new export infrastructure	সমাধান
`foo`	`bar`	Writes to a single table named after the identifier in app's binary ( `foo` )	Creates then writes to a single table named after the identifier set for Firebase App ( `bar` )	Implement either Option 1 or 2 described below.
`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 won'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 won't create a new table. Instead, it will maintain that table and start writing data for all apps to it.}

Options to avoid disruption

To avoid any disruptions, follow the instructions for one of the options described below before you manually upgrade or before January 9, 2026.

OPTION 1 :
Use the new table created by the new export infrastructure. You'll copy data from your existing table to the new table.
1. In the Firebase console, upgrade to the new export infrastructure by turning export off and then on again for the linked app.
  This action creates a new batch table with a name that's based on the bundle ID or package name set for your registered Firebase App in your Firebase project .
2. In the Google Cloud console, copy all the data from your legacy table to the new table that was just created.
3. If you have any downstream dependencies that depend on your batch table, change them to use the new table.
Note: Once you upgrade, new data will not write to your legacy table. Any previously written data in the legacy table won't be deleted.
OPTION 2 :
Continue writing to your existing table. You'll 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 Firebase console, upgrade to the new export infrastructure by turning export off and then on again for the linked app.
  This action does two things:
  - Creates a new batch table with a name that's based on the bundle ID or package name set for your registered Firebase App in your Firebase project . (You'll eventually delete this table, but do not delete it yet.)
  - Creates a BigQuery "data transfer config" with the source Firebase Crashlytics with Multi-Region Support .
3. In the Google Cloud console, change the new "data transfer config" so that data will continue to write to your existing 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.
4. Schedule a backfill for the days that your existing table is missing data.
5. Once the backfill is done, delete the new table that was automatically created by the new export infrastructure.

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

সমস্যা সারণীতে কিছু সমস্যার জন্য বিভিন্ন ফর্ম্যাট (এবং কখনও কখনও "ভেরিয়েন্ট") দেখা হচ্ছে

ব্রেডক্রাম্বের কাঠ দেখা যাচ্ছে না

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

ক্র্যাশ-মুক্ত মেট্রিক্স না দেখা (অথবা অবিশ্বস্ত মেট্রিক্স দেখা)

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

কে কোন বিষয়ে নোট দেখতে, লিখতে এবং মুছে ফেলতে পারে?

রিগ্রেসড ইস্যু কী?

পুরনো অ্যাপ ভার্সনের জন্য কেন আমি রিগ্রেসড সমস্যা দেখতে পাচ্ছি?

প্ল্যাটফর্ম-নির্দিষ্ট সহায়তা

অ্যাপল প্ল্যাটফর্ম সাপোর্ট

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

ক্র্যাশগুলিকে দুর্বলভাবে প্রতীকী করা হয়েছে

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

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

অ্যান্ড্রয়েড সাপোর্ট

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

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

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

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

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

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

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

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

Kotlin

Groovy

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

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

Kotlin

Groovy

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

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

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

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

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

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

ঐক্য সমর্থন

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

IL2CPP ব্যবহারকারী অ্যাপগুলির সাথে কি Crashlytics ব্যবহার করা যেতে পারে?

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

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

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

থ্রো করা ব্যতিক্রমগুলি ধরুন এবং পরিচালনা করুন

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

ইন্টিগ্রেশন সাপোর্ট

অ্যাপটি Google Mobile Ads SDK ব্যবহার করে কিন্তু ক্র্যাশ হচ্ছে না।

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

BigQuery জন্য নতুন রপ্তানি পরিকাঠামোতে কীভাবে আপগ্রেড করবেন?

আপনি নতুন অবকাঠামোতে আছেন কিনা তা নির্ধারণ করুন

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

ধাপ ১ : আপগ্রেড করার পূর্বশর্ত

Step 2 : Manually upgrade to the new infrastructure

Your existing batch table name doesn't match your Firebase App identifier

Understand how the export infrastructure uses identifiers to write data to BigQuery tables

What happens if this isn't fixed before upgrading?

Example scenarios of mismatched identifiers

Options to avoid disruption

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

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

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