বাগ রিপোর্ট পড়ুন

যেকোনো ধরনের ডেভেলপমেন্টে বাগ থাকাটা স্বাভাবিক—এবং সমস্যা শনাক্ত ও সমাধান করার জন্য বাগ রিপোর্ট অত্যন্ত গুরুত্বপূর্ণ। অ্যান্ড্রয়েডের সব ভার্সনই অ্যান্ড্রয়েড ডিবাগ ব্রিজ (adb) ব্যবহার করে বাগ রিপোর্ট গ্রহণ করা সমর্থন করে; অ্যান্ড্রয়েড ভার্সন ৪.২ এবং তার পরবর্তী ভার্সনগুলোতে বাগ রিপোর্ট গ্রহণ এবং ইমেল, ড্রাইভ ইত্যাদির মাধ্যমে শেয়ার করার জন্য একটি ডেভেলপার অপশন রয়েছে।

অ্যান্ড্রয়েড বাগ রিপোর্টে dumpsys , dumpstate , এবং logcat ডেটা টেক্সট (.txt) ফরম্যাটে থাকে, যা আপনাকে সহজেই নির্দিষ্ট বিষয়বস্তু অনুসন্ধান করতে সক্ষম করে। নিম্নলিখিত বিভাগগুলিতে বাগ রিপোর্টের উপাদানগুলির বিশদ বিবরণ, সাধারণ সমস্যাগুলির বর্ণনা এবং সেই বাগগুলির সাথে সম্পর্কিত লগগুলি খুঁজে বের করার জন্য সহায়ক টিপস ও grep কমান্ড দেওয়া হয়েছে। বেশিরভাগ বিভাগে grep কমান্ড ও তার আউটপুট এবং/অথবা dumpsys আউটপুটের উদাহরণও অন্তর্ভুক্ত রয়েছে।

লগক্যাট

logcat লগ হলো সমস্ত logcat তথ্যের একটি স্ট্রিং-ভিত্তিক ডাম্প। ' সিস্টেম' অংশটি ফ্রেমওয়ার্কের জন্য সংরক্ষিত এবং এর ইতিহাস 'মেইন'-এর চেয়ে দীর্ঘ, যেখানে বাকি সবকিছু থাকে। প্রতিটি লাইন সাধারণত timestamp UID PID TID log-level দিয়ে শুরু হয়, যদিও অ্যান্ড্রয়েডের পুরোনো সংস্করণগুলিতে UID তালিকাভুক্ত নাও থাকতে পারে।

ইভেন্ট লগ দেখুন

এই লগে বাইনারি-ফরম্যাটের লগ মেসেজগুলোর স্ট্রিং উপস্থাপনা থাকে। এটি logcat লগের চেয়ে কম কোলাহলপূর্ণ, কিন্তু পড়াটাও কিছুটা কঠিন। ইভেন্ট লগ দেখার সময়, কোনো প্রসেস কী করছিল তা দেখার জন্য আপনি এই বিভাগে নির্দিষ্ট প্রসেস আইডি (PID) দিয়ে অনুসন্ধান করতে পারেন। এর মৌলিক ফরম্যাটটি হলো: timestamp PID TID log-level log-tag tag-values ​​.

লগ লেভেলগুলোর মধ্যে নিম্নলিখিতগুলো অন্তর্ভুক্ত:

  • V: বিশদ
  • ডি: ডিবাগ
  • I: তথ্য
  • W: সতর্কবার্তা
  • ই: ত্রুটি

অন্যান্য দরকারি ইভেন্ট লগ ট্যাগের জন্য, /services/core/java/com/android/server/EventLogTags.logtags দেখুন।

ANR এবং ডেডলক

বাগরিপোর্ট আপনাকে অ্যাপ্লিকেশন নট রেসপন্ডিং (ANR) ত্রুটি এবং ডেডলক ইভেন্টের কারণ শনাক্ত করতে সাহায্য করতে পারে।

সাড়া না দেওয়া অ্যাপগুলি সনাক্ত করুন

যখন কোনো অ্যাপ্লিকেশন একটি নির্দিষ্ট সময়ের মধ্যে সাড়া দেয় না, সাধারণত প্রধান থ্রেড ব্লক বা ব্যস্ত থাকার কারণে, তখন সিস্টেম প্রসেসটিকে বন্ধ করে দেয় এবং স্ট্যাকটি /data/anr এ ডাম্প করে। একটি ANR-এর পেছনের কারণ খুঁজে বের করতে, বাইনারি ইভেন্ট লগে am_anr লিখে grep করুন।

আপনি logcat লগে ANR in grep-ও করতে পারেন, যেখানে ANR ঘটার সময় কোন জিনিসটি CPU ব্যবহার করছিল সে সম্পর্কে আরও তথ্য থাকে।

স্ট্যাক ট্রেস খুঁজুন

আপনি প্রায়শই ANR-এর সাথে সম্পর্কিত স্ট্যাক ট্রেস খুঁজে পেতে পারেন। নিশ্চিত করুন যে VM ট্রেসের টাইমস্ট্যাম্প এবং PID, আপনি যে ANR-টি তদন্ত করছেন তার সাথে মিলছে, তারপর প্রসেসটির প্রধান থ্রেডটি পরীক্ষা করুন। মনে রাখবেন:

  • মূল থ্রেডটি আপনাকে কেবল এটুকুই জানায় যে ANR-এর সময় থ্রেডটি কী করছিল, যা ANR-এর প্রকৃত কারণের সাথে মিলতে পারে বা নাও মিলতে পারে। (বাগ রিপোর্টের স্ট্যাকটি নিরীহ হতে পারে; অন্য কিছু হয়তো দীর্ঘ সময় ধরে আটকে ছিল—কিন্তু ANR হওয়ার মতো যথেষ্ট দীর্ঘ সময় নয়—এবং পরে তা সচল হয়েছে।)
  • একাধিক স্ট্যাক ট্রেস সেট ( VM TRACES JUST NOW এবং VM TRACES AT LAST ANR ) থাকতে পারে। নিশ্চিত করুন যে আপনি সঠিক বিভাগটি দেখছেন।

ডেডলক খুঁজুন

ডেডলক প্রায়শই প্রথমে ANR (অ্যাক্টিভ রেসপন্স) হিসাবে দেখা দেয়, কারণ থ্রেডগুলো আটকে যায়। যদি ডেডলকটি সিস্টেম সার্ভারকে প্রভাবিত করে, তবে ওয়াচডগ অবশেষে সেটিকে কিল করে দেয়, যার ফলে লগে WATCHDOG KILLING SYSTEM PROCESS এর মতো একটি এন্ট্রি দেখা যায়। ব্যবহারকারীর দৃষ্টিকোণ থেকে, ডিভাইসটি রিবুট হয়, যদিও প্রযুক্তিগতভাবে এটি একটি রানটাইম রিস্টার্ট, সত্যিকারের রিবুট নয়।

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

ডেডলক খুঁজে বের করার জন্য, ভিএম ট্রেস সেকশনগুলোতে এমন একটি প্যাটার্ন খুঁজুন যেখানে থ্রেড A, থ্রেড B-এর দখলে থাকা কোনো কিছুর জন্য অপেক্ষা করছে এবং থ্রেড B আবার থ্রেড A-এর দখলে থাকা কোনো কিছুর জন্য অপেক্ষা করছে।

কার্যকলাপ

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

নির্দিষ্ট কার্যক্রম দেখুন

মনোযোগী কার্যকলাপের ইতিহাস দেখতে, am_focused_activity লিখে অনুসন্ধান করুন।

দেখার প্রক্রিয়া শুরু হয়

প্রসেস শুরুর ইতিহাস দেখতে, Start proc লিখে অনুসন্ধান করুন।

ডিভাইসটি থ্র্যাশিং করছে কিনা তা নির্ণয় করুন।

ডিভাইসটি থ্র্যাশিং হচ্ছে কিনা তা নির্ধারণ করতে, am_proc_died এবং am_proc_start আশেপাশে অল্প সময়ের মধ্যে অ্যাক্টিভিটির অস্বাভাবিক বৃদ্ধি লক্ষ্য করুন।

স্মৃতি

যেহেতু অ্যান্ড্রয়েড ডিভাইসগুলিতে প্রায়শই সীমিত ফিজিক্যাল মেমরি থাকে, তাই র‍্যান্ডম-অ্যাক্সেস মেমরি (RAM) পরিচালনা করা অত্যন্ত গুরুত্বপূর্ণ। বাগ রিপোর্টগুলিতে কম মেমরির বিভিন্ন সূচকের পাশাপাশি একটি ডাম্পস্টেট থাকে, যা মেমরির একটি স্ন্যাপশট প্রদান করে।

কম স্মৃতিশক্তি শনাক্ত করুন

মেমোরি কম থাকলে সিস্টেম থ্র্যাশ করতে পারে, কারণ এটি মেমোরি খালি করার জন্য কিছু প্রসেস বন্ধ করে দিলেও অন্যান্য প্রসেস চালু রাখতে থাকে। মেমোরি কম থাকার নিশ্চিত প্রমাণ দেখতে, বাইনারি ইভেন্ট লগে am_proc_died এবং am_proc_start এন্ট্রিগুলোর উপস্থিতি পরীক্ষা করুন।

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

ঐতিহাসিক সূচকগুলি দেখুন

বাইনারি ইভেন্ট লগে am_low_memory এন্ট্রিটি নির্দেশ করে যে সর্বশেষ ক্যাশ করা প্রসেসটি বন্ধ হয়ে গেছে। এর পরে, সিস্টেম সার্ভিসগুলো বন্ধ করতে শুরু করে।

থ্র্যাশিং সূচকগুলি দেখুন

সিস্টেম থ্র্যাশিং-এর অন্যান্য সূচকগুলোর (পেজিং, ডাইরেক্ট রিক্লেইম, ইত্যাদি) মধ্যে রয়েছে kswapd , kworker , এবং mmcqd সাইকেল খরচ। (মনে রাখবেন, বাগরিপোর্ট সংগ্রহের বিষয়টি থ্র্যাশিং সূচকগুলোকে প্রভাবিত করতে পারে।)

ANR লগগুলোও অনুরূপ একটি মেমরি স্ন্যাপশট প্রদান করতে পারে।

স্মৃতির একটি স্ন্যাপশট নিন

মেমরি স্ন্যাপশট হলো একটি ডাম্পস্টেট যা চলমান জাভা এবং নেটিভ প্রসেসগুলোর তালিকা দেখায় (বিস্তারিত জানতে, ‘সামগ্রিক মেমরি বরাদ্দ দেখা’ দেখুন)। মনে রাখবেন, স্ন্যাপশটটি শুধুমাত্র একটি নির্দিষ্ট মুহূর্তের অবস্থা দেখায়; স্ন্যাপশট নেওয়ার আগে সিস্টেমটি আরও ভালো (বা খারাপ) অবস্থায় থাকতে পারত।

সম্প্রচার

অ্যাপ্লিকেশনগুলো বর্তমান অ্যাপ্লিকেশনের মধ্যে বা অন্য কোনো অ্যাপ্লিকেশনে ইভেন্ট পাঠানোর জন্য ব্রডকাস্ট তৈরি করে। ব্রডকাস্ট রিসিভাররা (ফিল্টারের মাধ্যমে) নির্দিষ্ট মেসেজ সাবস্ক্রাইব করে, যা তাদের একটি ব্রডকাস্ট শোনা এবং তাতে সাড়া দেওয়া—উভয়ই করতে সক্ষম করে। বাগ রিপোর্টে পাঠানো এবং না পাঠানো ব্রডকাস্ট সম্পর্কিত তথ্যের পাশাপাশি একটি নির্দিষ্ট ব্রডকাস্ট শুনছে এমন সমস্ত রিসিভারের একটি ডাম্পসিস ফাইলও থাকে।

ঐতিহাসিক সম্প্রচারগুলি দেখুন

ঐতিহাসিক সম্প্রচারগুলো হলো সেগুলো যা ইতিমধ্যেই পাঠানো হয়েছে, এবং এগুলোকে বিপরীত কালানুক্রমিক ক্রমে তালিকাভুক্ত করা হয়েছে।

সারাংশ বিভাগে শেষ ৩০০টি ফোরগ্রাউন্ড ব্রডকাস্ট এবং শেষ ৩০০টি ব্যাকগ্রাউন্ড ব্রডকাস্টের একটি সংক্ষিপ্ত বিবরণ দেওয়া হয়েছে।

বিস্তারিত বিভাগে শেষ ৫০টি ফোরগ্রাউন্ড সম্প্রচার এবং শেষ ৫০টি ব্যাকগ্রাউন্ড সম্প্রচারের সম্পূর্ণ তথ্যের পাশাপাশি প্রতিটি সম্প্রচারের রিসিভারগুলোর তথ্যও রয়েছে। যে রিসিভারগুলোর রয়েছে:

  • BroadcastFilter এন্ট্রিগুলো রানটাইমে নিবন্ধিত হয় এবং শুধুমাত্র আগে থেকে চলমান প্রসেসগুলোতে পাঠানো হয়।
  • ResolveInfo এন্ট্রিগুলো ম্যানিফেস্ট এন্ট্রির মাধ্যমে নিবন্ধিত হয়। যদি প্রসেসটি আগে থেকে চালু না থাকে, তবে ActivityManager প্রতিটি ResolveInfo জন্য তা চালু করে।

সক্রিয় সম্প্রচারগুলি দেখুন

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

সম্প্রচার শ্রোতাদের দেখুন

কোনো ব্রডকাস্টের জন্য লিসেনিং করা রিসিভারদের তালিকা দেখতে, dumpsys activity broadcasts এ থাকা Receiver Resolver Table-টি দেখুন। নিচের উদাহরণটি USER_PRESENT জন্য লিসেনিং করা সমস্ত রিসিভারকে প্রদর্শন করে।

বিরোধ পর্যবেক্ষণ করুন

মনিটর কনটেনশন লগিং কখনও কখনও প্রকৃত মনিটর কনটেনশন নির্দেশ করতে পারে, তবে বেশিরভাগ ক্ষেত্রেই এটি বোঝায় যে সিস্টেমটি এতটাই ভারাক্রান্ত যে সবকিছু ধীর হয়ে গেছে। আপনি সিস্টেম বা ইভেন্ট লগে ART দ্বারা লগ করা দীর্ঘ মনিটর ইভেন্ট দেখতে পারেন।

সিস্টেম লগে:

10-01 18:12:44.343 29761 29914 W art     : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s

ইভেন্ট লগে:

10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]

পটভূমি সংকলন

সংকলন ব্যয়বহুল হতে পারে এবং ডিভাইসের উপর চাপ সৃষ্টি করতে পারে।

গুগল প্লে স্টোরের আপডেট ডাউনলোড হওয়ার সময় ব্যাকগ্রাউন্ডে কম্পাইলেশন হতে পারে। এক্ষেত্রে, গুগল প্লে স্টোর অ্যাপ ( finsky ) এবং installd মেসেজগুলো dex2oat মেসেজের আগে দেখা যায়।

যখন কোনো অ্যাপ্লিকেশন এমন একটি ডেক্স ফাইল লোড করে যা এখনো কম্পাইল করা হয়নি, তখন ব্যাকগ্রাউন্ডেও কম্পাইলেশন হতে পারে। এই ক্ষেত্রে, আপনি finsky বা installd লগিং দেখতে পাবেন না।

আখ্যান

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

টাইমলাইন সিঙ্ক করুন

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

সিস্টেম এবং ইভেন্ট লগের টাইমস্ট্যাম্পগুলো ব্যবহারকারীর টাইমজোনের মধ্যেই থাকে (অন্যান্য বেশিরভাগ টাইমস্ট্যাম্পের মতোই)। উদাহরণস্বরূপ, যখন ব্যবহারকারী হোম বোতামে ট্যাপ করেন, তখন সিস্টেম লগ রিপোর্ট করে:

10-03 17:19:52.939  1963  2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0

একই কাজের জন্য, ইভেন্ট লগ রিপোর্ট করে:

10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

কার্নেল ( dmesg ) লগ একটি ভিন্ন সময় ভিত্তি ব্যবহার করে, যা বুটলোডার সম্পূর্ণ হওয়ার পর থেকে সেকেন্ডে লগ আইটেমগুলোকে ট্যাগ করে। এই টাইমস্কেলকে অন্যান্য টাইমস্কেলের সাথে রেজিস্টার করতে, suspend exit এবং suspend entry মেসেজগুলো সার্চ করুন:

<6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
…
<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC

যেহেতু সাসপেন্ড থাকা অবস্থায় কার্নেল লগে সময় অন্তর্ভুক্ত নাও থাকতে পারে, তাই সাসপেন্ড এন্ট্রি এবং এক্সিট মেসেজের মাঝে লগটি পর্যায়ক্রমে রেজিস্টার করা উচিত। এছাড়াও, কার্নেল লগ UTC টাইমজোন ব্যবহার করে এবং এটিকে অবশ্যই ইউজার টাইমজোনের সাথে সমন্বয় করতে হবে।

বাগরিপোর্টের সময় শনাক্ত করুন

কখন একটি বাগরিপোর্ট নেওয়া হয়েছিল তা নির্ধারণ করতে, প্রথমে সিস্টেম লগ (Logcat)-এ dumpstate: begin : চেক করুন।

10-03 17:19:54.322 19398 19398 I dumpstate: begin

এরপরে, Starting service 'bugreport' মেসেজটির জন্য কার্নেল লগ ( dmesg )-এর টাইমস্ট্যাম্পগুলো পরীক্ষা করুন:

<5>[207064.285315] init: Starting service 'bugreport'...

টাইমলাইন সিঙ্ক করার ক্ষেত্রে উল্লিখিত সতর্কবার্তাগুলো মাথায় রেখে, দুটি ঘটনার মধ্যে সম্পর্ক স্থাপন করতে পেছনের দিক থেকে কাজ করুন। যদিও বাগরিপোর্ট শুরু করার পর অনেক কিছু ঘটে, তবে বেশিরভাগ কার্যকলাপই খুব একটা কাজের হয় না, কারণ বাগরিপোর্টটি গ্রহণ করার কাজটি সিস্টেমের উপর যথেষ্ট চাপ সৃষ্টি করে।

শক্তি

ইভেন্ট লগে স্ক্রিনের পাওয়ার স্ট্যাটাস থাকে, যেখানে ০ মানে স্ক্রিন বন্ধ, ১ মানে স্ক্রিন চালু এবং ২ মানে কীগার্ড সম্পন্ন হয়েছে।

বাগ রিপোর্টে ওয়েক লক সম্পর্কিত পরিসংখ্যানও থাকে। ওয়েক লক হলো এমন একটি কৌশল যা অ্যাপ্লিকেশন ডেভেলপাররা তাদের অ্যাপ্লিকেশনের জন্য ডিভাইসটি চালু রাখার প্রয়োজনীয়তা বোঝাতে ব্যবহার করেন। (ওয়েক লক সম্পর্কে বিস্তারিত জানতে PowerManager.WakeLock এবং Keep the CPU on দেখুন।)

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

পাওয়ার স্ট্যাটাস আরও ভালোভাবে দেখার জন্য, ব্যাটারি হিস্টোরিয়ান (Battery Historian) ব্যবহার করুন; এটি গুগলের একটি ওপেন সোর্স টুল যা অ্যান্ড্রয়েড বাগরিপোর্ট ফাইল ব্যবহার করে ব্যাটারির ব্যবহার বিশ্লেষণ করে।

প্যাকেজ

DUMP OF SERVICE package বিভাগে অ্যাপ্লিকেশন সংস্করণ (এবং অন্যান্য দরকারী তথ্য) থাকে।

প্রক্রিয়া

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

প্রক্রিয়ার রানটাইম নির্ধারণ করুন

procstats বিভাগে প্রসেস এবং সংশ্লিষ্ট সার্ভিসগুলো কতক্ষণ ধরে চলছে তার সম্পূর্ণ পরিসংখ্যান থাকে। দ্রুত ও সহজে পাঠযোগ্য একটি সারসংক্ষেপের জন্য, গত তিন বা ২৪ ঘণ্টার ডেটা দেখতে AGGREGATED OVER লিখে সার্চ করুন, এরপর প্রসেসগুলোর তালিকা, বিভিন্ন প্রায়োরিটিতে সেই প্রসেসগুলো কতক্ষণ ধরে চলেছে এবং min-average-max PSS/min-average-max USS ফরম্যাটে তাদের র‍্যাম ব্যবহারের পরিমাণ দেখতে ‘ Summary: লিখে সার্চ করুন।

একটি প্রক্রিয়া চলার কারণ

dumpsys activity processes সেকশনটি বর্তমানে চলমান সমস্ত প্রসেসকে oom_adj স্কোর অনুসারে তালিকাভুক্ত করে (অ্যান্ড্রয়েড প্রসেসকে একটি oom_adj ভ্যালু দিয়ে তার গুরুত্ব নির্দেশ করে, যা ActivityManager দ্বারা ডায়নামিকভাবে আপডেট করা যায়)। এর আউটপুট একটি মেমরি স্ন্যাপশটের মতোই, তবে এতে প্রসেসটি কী কারণে চলছে সে সম্পর্কে অতিরিক্ত তথ্য থাকে। নীচের উদাহরণে, বোল্ড করা এন্ট্রিগুলি নির্দেশ করে যে gms.persistent প্রসেসটি vis (visible) প্রায়োরিটিতে চলছে, কারণ সিস্টেম প্রসেসটি তার NetworkLocationService সাথে আবদ্ধ।

স্ক্যান

অতিরিক্ত ব্লুটুথ লো এনার্জি (BLE) স্ক্যান সম্পাদনকারী অ্যাপ্লিকেশনগুলি শনাক্ত করতে নিম্নলিখিত ধাপগুলি অনুসরণ করুন:

  • BluetoothLeScanner এর জন্য লগ বার্তাগুলি খুঁজুন:
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • লগ মেসেজগুলো থেকে PID-টি খুঁজে বের করুন। এই উদাহরণে, "24840" এবং "24851" হলো PID (প্রসেস আইডি) এবং TID (থ্রেড আইডি)।
  • PID-এর সাথে যুক্ত অ্যাপ্লিকেশনটি সনাক্ত করুন:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    

    এই উদাহরণে, প্যাকেজের নাম হলো com.badapp

  • দায়ী অ্যাপ্লিকেশনটি শনাক্ত করতে গুগল প্লে-তে প্যাকেজ নামটি দেখুন: https://play.google.com/store/apps/details?id=com.badapp

দ্রষ্টব্য : অ্যান্ড্রয়েড ৭.০ চালিত ডিভাইসগুলির ক্ষেত্রে, সিস্টেম BLE স্ক্যানের জন্য ডেটা সংগ্রহ করে এবং এই কার্যকলাপগুলিকে সূচনাকারী অ্যাপ্লিকেশনের সাথে যুক্ত করে। বিস্তারিত জানতে, লো এনার্জি (LE) এবং ব্লুটুথ স্ক্যান দেখুন।