সমস্যার রিপোর্ট পড়ুন

যেকোনও ধরনের ডেভেলপমেন্টের ক্ষেত্রে বাগ একটি বাস্তব ঘটনা—এবং সমস্যা শনাক্ত ও সমাধান করার জন্য বাগ রিপোর্ট অত্যন্ত গুরুত্বপূর্ণ। Android-এর সব ভার্সন Android Debug Bridge (adb)-এর মাধ্যমে বাগ রিপোর্ট ক্যাপচার করার সুবিধা দেয়; Android 4.2 ও এর পরবর্তী যেকোনও ভার্সনে বাগ রিপোর্ট নেওয়ার জন্য ডেভেলপার বিকল্প থাকে এবং ইমেল, Drive ইত্যাদির মাধ্যমে তা শেয়ার করা যায়।

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

Logcat

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

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

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

লগ লেভেলে নিম্নলিখিত বিষয়গুলি অন্তর্ভুক্ত:

  • V: verbose
  • D: ডিবাগ
  • I: তথ্য
  • W: সতর্কতা
  • E: সমস্যা

 

অন্যান্য প্রয়োজনীয় ইভেন্ট লগ ট্যাগের জন্য, /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. ব্যবহারকারীর দৃষ্টিকোণ থেকে, ডিভাইসটি রিবুট হয়, যদিও প্রযুক্তিগতভাবে এটি একটি রানটাইম রিস্টার্ট, আসল রিবুট নয়।

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

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

অ্যাক্টিভিটি

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

ফোকাস করা অ্যাক্টিভিটি দেখা

ফোকাস করা অ্যাক্টিভিটির ইতিহাস দেখতে, am_focused_activity সার্চ করুন।

ভিউ প্রসেস শুরু হয়

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

ডিভাইস থ্র্যাশিং করছে কিনা তা নির্ধারণ করা

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

মেমরি

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

কম মেমরি শনাক্ত করুন

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

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

ঐতিহাসিক সূচক দেখা

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

থ্র্যাশিং ইন্ডিকেটর দেখুন

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

ANR লগ একই ধরনের মেমরি স্ন্যাপশট প্রদান করতে পারে।

মেমরির স্ন্যাপশট পাওয়া

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

ব্রডকাস্ট

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

পুরনো ব্রডকাস্ট দেখুন

ইতিহাসের ব্রডকাস্ট হল সেগুলি যা ইতিমধ্যেই পাঠানো হয়েছে এবং উল্টো কালানুক্রমিক ক্রমে তালিকাভুক্ত করা হয়েছে।

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

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

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

চালু থাকা ব্রডকাস্ট দেখা

অ্যাক্টিভ ব্রডকাস্ট হল সেইসব ব্রডকাস্ট যা এখনও পাঠানো হয়নি। কিউতে থাকা আইটেমের সংখ্যা অনেক বেশি হলে বুঝতে হবে যে সিস্টেমটি দ্রুত যথেষ্ট ব্রডকাস্ট ডিসপ্যাচ করতে পারছে না।

ব্রডকাস্টের শ্রোতা দেখা

ব্রডকাস্ট শোনার জন্য প্রস্তুত রিসিভারের তালিকা দেখতে, dumpsys activity broadcasts-এ রিসিভার রেজোলভার টেবিল চেক করুন। নিচে দেওয়া উদাহরণে 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]

ব্যাকগ্রাউন্ড কম্পাইলেশন

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

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

এছাড়াও, কোনও অ্যাপ্লিকেশন এখনও কম্পাইল করা হয়নি এমন কোনও dex ফাইল লোড করলে ব্যাকগ্রাউন্ডে কম্পাইলেশন হতে পারে। এই ক্ষেত্রে, আপনি 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) লগে আলাদা টাইম বেস ব্যবহার করা হয়, বুটলোডার সম্পূর্ণ হওয়ার পর থেকে সেকেন্ডের সাথে লগ আইটেম ট্যাগ করা হয়। অন্যান্য টাইমস্কেলে এই টাইমস্কেল রেজিস্টার করতে, সাসপেন্ড এক্সিট ও সাসপেন্ড এন্ট্রি মেসেজ সার্চ করুন:

<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 টাইমজোন ব্যবহার করে এবং ব্যবহারকারীর টাইমজোনের সাথে অ্যাডজাস্ট করতে হবে।

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

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

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

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

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

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

বিদ্যুৎ

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

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

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

পাওয়ার স্ট্যাটাস ভিজ্যুয়ালাইজ করার ব্যাপারে আরও সাহায্য পেতে, Battery Historian ব্যবহার করুন, এটি হল Google-এর ওপেন সোর্স টুল যা Android বাগরিপোর্ট ফাইল ব্যবহার করে ব্যাটারি কনজিউমার বিশ্লেষণ করে।

প্যাকেজ

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

প্রক্রিয়াগুলি

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

প্রসেস রানটাইম নির্ধারণ করুন

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

কোনও প্রসেস চলার কারণ

dumpsys activity processes বিভাগে বর্তমানে চলছে এমন সব প্রসেস oom_adj স্কোর অনুযায়ী সাজানো থাকে (Android কোনও প্রসেসের গুরুত্ব বোঝাতে সেটিকে একটি oom_adj ভ্যালু অ্যাসাইন করে, যা ActivityManager-এর মাধ্যমে ডায়নামিকভাবে আপডেট করা যায়)। আউটপুটটি মেমরি স্ন্যাপশটের মতো, তবে এতে প্রসেসটি রান করার কারণ সম্পর্কে অতিরিক্ত তথ্য অন্তর্ভুক্ত থাকে। নিচের উদাহরণে, বোল্ড করা এন্ট্রিগুলি ইঙ্গিত করে যে gms.persistent প্রসেসটি vis (দৃশ্যমান) অগ্রাধিকারের সাথে রান করছে কারণ সিস্টেম প্রসেসটি এর 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.

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

মনে রাখবেন: Android 7.0 ভার্সনে চলা ডিভাইসের জন্য, সিস্টেম BLE স্ক্যানের জন্য ডেটা সংগ্রহ করে এবং এই অ্যাক্টিভিটিগুলি যে অ্যাপ্লিকেশন শুরু করেছে তার সাথে অ্যাসোসিয়েট করে। বিস্তারিত জানতে, লো এনার্জি (LE) ও ব্লুটুথ স্ক্যান দেখুন।