گزارش های اشکال را بخوانید

باگ‌ها در هر نوع توسعه‌ای یک واقعیت هستند - و گزارش‌های باگ برای شناسایی و حل مشکلات بسیار مهم هستند. همه نسخه‌های اندروید از ثبت گزارش‌های باگ با Android Debug Bridge (adb) پشتیبانی می‌کنند؛ نسخه‌های اندروید ۴.۲ و بالاتر از گزینه توسعه‌دهنده برای دریافت گزارش‌های باگ و اشتراک‌گذاری از طریق ایمیل، درایو و غیره پشتیبانی می‌کنند.

گزارش‌های باگ اندروید حاوی داده‌های dumpsys ، dumpstate و logcat در قالب متن (.txt) هستند که به شما امکان می‌دهند به راحتی محتوای خاص را جستجو کنید. بخش‌های زیر اجزای گزارش باگ را شرح می‌دهند، مشکلات رایج را شرح می‌دهند و نکات مفید و دستورات grep را برای یافتن گزارش‌های مرتبط با آن باگ‌ها ارائه می‌دهند. اکثر بخش‌ها همچنین شامل مثال‌هایی برای دستور grep و خروجی و/یا خروجی dumpsys هستند.

لاگ‌کت

لاگ logcat یک dump مبتنی بر رشته از تمام اطلاعات logcat است. بخش system برای فریم‌ورک رزرو شده است و تاریخچه طولانی‌تری نسبت به main دارد که شامل همه چیز دیگر است. هر خط معمولاً با timestamp UID PID TID log-level شروع می‌شود، اگرچه ممکن است UID در نسخه‌های قدیمی‌تر اندروید فهرست نشده باشد.

مشاهده گزارش رویداد

این لاگ شامل نمایش‌های رشته‌ای از پیام‌های لاگ با فرمت دودویی است. نسبت به لاگ logcat نویز کمتری دارد، اما خواندن آن نیز کمی دشوارتر است. هنگام مشاهده لاگ‌های رویداد، می‌توانید در این بخش شناسه فرآیند خاص (PID) را جستجو کنید تا ببینید یک فرآیند چه کاری انجام داده است. فرمت اصلی به این صورت است: timestamp PID TID log-level log-tag tag-values ​​.

سطوح ثبت وقایع شامل موارد زیر است:

  • V: مفصل
  • د: اشکال‌زدایی
  • من: اطلاعات
  • W: هشدار
  • ه: خطا

برای سایر تگ‌های مفید ثبت وقایع، به /services/core/java/com/android/server/EventLogTags.logtags مراجعه کنید.

ANRها و بن‌بست‌ها

Bugreports می‌تواند به شما در شناسایی علت خطاهای عدم پاسخگویی برنامه (ANR) و رویدادهای بن‌بست کمک کند.

شناسایی برنامه‌های غیرفعال

وقتی یک برنامه در مدت زمان مشخصی پاسخ نمی‌دهد، معمولاً به دلیل مسدود شدن یا مشغول بودن نخ اصلی، سیستم فرآیند را متوقف کرده و پشته را در /data/anr تخلیه می‌کند. برای کشف مقصر پشت یک ANR، در گزارش رویداد دودویی grep for am_anr را تایپ کنید.

همچنین می‌توانید در لاگ logcat عبارت ANR in را با grep جستجو کنید، که شامل اطلاعات بیشتری در مورد آنچه در زمان ANR از CPU استفاده می‌کرده است، می‌باشد.

یافتن ردپاهای پشته

اغلب می‌توانید ردپاهای پشته‌ای را پیدا کنید که با یک ANR مطابقت دارند. مطمئن شوید که برچسب زمانی و PID روی ردپاهای ماشین مجازی با ANR مورد بررسی شما مطابقت دارند، سپس نخ اصلی فرآیند را بررسی کنید. به خاطر داشته باشید:

  • رشته اصلی فقط به شما می‌گوید که رشته در زمان ANR چه کاری انجام می‌داد، که ممکن است با علت واقعی ANR مطابقت داشته باشد یا نداشته باشد. (ممکن است پشته موجود در گزارش اشکال بی‌ضرر باشد؛ ممکن است چیز دیگری برای مدت طولانی - اما نه به اندازه کافی طولانی که ANR شود - قبل از اینکه از حالت انسداد خارج شود، گیر کرده باشد.)
  • ممکن است بیش از یک مجموعه از ردیابی‌های پشته ( VM TRACES JUST NOW و VM TRACES AT LAST ANR ) وجود داشته باشد. مطمئن شوید که بخش صحیح را مشاهده می‌کنید.

پیدا کردن بن‌بست‌ها

بن‌بست‌ها اغلب ابتدا به صورت ANR ظاهر می‌شوند زیرا رشته‌ها گیر می‌کنند. اگر بن‌بست به سرور سیستم برخورد کند، watchdog در نهایت آن را از بین می‌برد و منجر به ورودی در گزارش مشابه: WATCHDOG KILLING SYSTEM PROCESS می‌شود. از دید کاربر، دستگاه مجدداً راه‌اندازی می‌شود، اگرچه از نظر فنی این یک راه‌اندازی مجدد در زمان اجرا است نه یک راه‌اندازی مجدد واقعی.

  • در یک راه‌اندازی مجدد در زمان اجرا ، سرور سیستم از کار می‌افتد و مجدداً راه‌اندازی می‌شود؛ کاربر شاهد بازگشت دستگاه به انیمیشن بوت است.
  • در یک راه‌اندازی مجدد ، هسته از کار افتاده است؛ کاربر می‌بیند که دستگاه به لوگوی بوت گوگل بازمی‌گردد.

برای یافتن بن‌بست‌ها، بخش‌های ردیابی ماشین مجازی را برای یافتن الگویی از نخ A که منتظر چیزی است که توسط نخ B نگهداری می‌شود، بررسی کنید، که به نوبه خود منتظر چیزی است که توسط نخ A نگهداری می‌شود.

فعالیت‌ها

یک فعالیت (Activity) یک جزء برنامه است که صفحه‌ای را در اختیار کاربران قرار می‌دهد تا با آن تعامل داشته باشند و کارهایی مانند شماره‌گیری، گرفتن عکس، ارسال ایمیل و غیره را انجام دهند. از دیدگاه گزارش اشکال (bug report)، یک فعالیت یک کار واحد و متمرکز است که کاربر می‌تواند انجام دهد، و این امر یافتن فعالیتی را که در حین خرابی در کانون توجه بوده است، بسیار مهم می‌کند. فعالیت‌ها (از طریق ActivityManager) فرآیندها را اجرا می‌کنند، بنابراین یافتن تمام توقف‌ها و شروع‌های فرآیند برای یک فعالیت خاص می‌تواند به عیب‌یابی نیز کمک کند.

مشاهده فعالیت‌های متمرکز

برای مشاهده سابقه فعالیت‌های متمرکز، am_focused_activity را جستجو کنید.

مشاهده شروع فرآیند

برای مشاهده‌ی تاریخچه‌ی شروع فرآیندها، عبارت Start proc را جستجو کنید.

تشخیص دهید که آیا دستگاه در حال کار کردن است یا خیر

برای تشخیص اینکه آیا دستگاه در حال کار کردن است یا خیر، افزایش غیرعادی فعالیت در اطراف am_proc_died و am_proc_start را در مدت زمان کوتاهی بررسی کنید.

حافظه

از آنجا که دستگاه‌های اندروید اغلب حافظه فیزیکی محدودی دارند، مدیریت حافظه با دسترسی تصادفی (RAM) بسیار مهم است. گزارش‌های باگ شامل چندین شاخص کمبود حافظه و همچنین یک dumpstate هستند که یک تصویر لحظه‌ای از حافظه ارائه می‌دهد.

شناسایی حافظه کم

کمبود حافظه می‌تواند باعث شود سیستم به شدت کند شود، زیرا برخی از فرآیندها را برای آزادسازی حافظه از بین می‌برد اما همچنان فرآیندهای دیگر را شروع می‌کند. برای مشاهده شواهد تأییدکننده کمبود حافظه، غلظت ورودی‌های am_proc_died و am_proc_start را در گزارش رویداد دودویی بررسی کنید.

کمبود حافظه همچنین می‌تواند تغییر وظیفه را کند کرده و تلاش‌های بازگشت را خنثی کند (زیرا وظیفه‌ای که کاربر سعی در بازگشت به آن داشت، از بین رفته است). اگر لانچر از بین رفته باشد، هنگامی که کاربر دکمه خانه را لمس می‌کند، مجدداً راه‌اندازی می‌شود و گزارش‌ها نشان می‌دهند که لانچر محتوای خود را مجدداً بارگذاری می‌کند.

مشاهده شاخص‌های تاریخی

ورودی am_low_memory در گزارش رویداد دودویی نشان می‌دهد که آخرین فرآیند ذخیره شده در حافظه پنهان از بین رفته است. پس از این، سیستم شروع به از بین بردن سرویس‌ها می‌کند.

مشاهده شاخص‌های ضربه

سایر شاخص‌های thrashing سیستم (صفحه‌بندی، بازیابی مستقیم و غیره) شامل چرخه‌های مصرف kswapd ، kworker و mmcqd است. (به خاطر داشته باشید که گزارش اشکال جمع‌آوری‌شده می‌تواند بر شاخص‌های thrashing تأثیر بگذارد.)

لاگ‌های ANR می‌توانند یک اسنپ‌شات حافظه مشابه ارائه دهند.

یک عکس فوری از حافظه بگیرید

اسنپ‌شات حافظه، یک dumpstate است که فرآیندهای جاوا و بومی در حال اجرا را فهرست می‌کند (برای جزئیات بیشتر، به «مشاهده تخصیص کلی حافظه » مراجعه کنید). به خاطر داشته باشید که اسنپ‌شات فقط وضعیت را در یک لحظه خاص از زمان ارائه می‌دهد؛ سیستم ممکن است قبل از اسنپ‌شات در وضعیت بهتری (یا بدتری) بوده باشد.

پخش‌ها

برنامه‌ها، اعلان‌هایی (broadcasts) تولید می‌کنند تا رویدادها را درون برنامه فعلی یا به برنامه دیگری ارسال کنند. گیرنده‌های اعلان، پیام‌های خاصی را (از طریق فیلترها) دریافت می‌کنند که آنها را قادر می‌سازد هم به یک اعلان گوش دهند و هم به آن پاسخ دهند. گزارش‌های اشکال (bug reports) حاوی اطلاعاتی در مورد اعلان‌های ارسالی و اعلان‌های ارسال نشده و همچنین مجموعه‌ای از تمام گیرنده‌هایی است که به یک اعلان خاص گوش می‌دهند.

مشاهده پخش‌های تاریخی

پخش‌های تاریخی، آن‌هایی هستند که قبلاً ارسال شده‌اند و به ترتیب زمانی معکوس فهرست شده‌اند.

بخش خلاصه ، مروری بر ۳۰۰ پخش پیش‌زمینه آخر و ۳۰۰ پخش پس‌زمینه آخر است.

بخش جزئیات شامل اطلاعات کاملی برای ۵۰ پخش پیش‌زمینه و ۵۰ پخش پس‌زمینه آخر، و همچنین گیرنده‌های هر پخش است. گیرنده‌هایی که:

  • ورودی‌های BroadcastFilter در زمان اجرا ثبت می‌شوند و فقط به فرآیندهای در حال اجرا ارسال می‌شوند.
  • ورودی‌های ResolveInfo از طریق ورودی‌های مانیفست ثبت می‌شوند. ActivityManager اگر ResolveInfo از قبل اجرا نشده باشد، فرآیند را برای هر کدام از آن‌ها آغاز می‌کند.

مشاهده پخش‌های فعال

پخش‌های فعال، پخش‌هایی هستند که هنوز ارسال نشده‌اند. تعداد زیاد در صف به این معنی است که سیستم نمی‌تواند پخش‌ها را به اندازه کافی سریع ارسال کند تا بتواند به کار خود ادامه دهد.

مشاهده شنوندگان پخش

برای مشاهده لیستی از گیرنده‌هایی که به یک broadcast گوش می‌دهند، جدول Receiver Resolver را در 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]

تدوین پس‌زمینه

کامپایل کردن می‌تواند پرهزینه باشد و دستگاه را بارگذاری کند.

ممکن است هنگام دانلود به‌روزرسانی‌های فروشگاه گوگل پلی، کامپایل در پس‌زمینه انجام شود. در این حالت، پیام‌های برنامه فروشگاه گوگل پلی ( finsky ) و installd قبل از پیام‌های dex2oat ظاهر می‌شوند.

همچنین ممکن است کامپایل در پس‌زمینه رخ دهد، زمانی که یک برنامه در حال بارگذاری یک فایل dex است که هنوز کامپایل نشده است. در این حالت، گزارش‌گیری finsky یا installd را نخواهید دید.

روایت

شرح روایت یک مشکل (نحوه شروع، چه اتفاقی افتاد، سیستم چگونه واکنش نشان داد) نیاز به یک جدول زمانی دقیق از وقایع دارد. می‌توانید از اطلاعات موجود در گزارش اشکال برای همگام‌سازی جدول‌های زمانی در چندین گزارش و تعیین زمان دقیق گزارش اشکال استفاده کنید.

همگام‌سازی جدول زمانی

یک گزارش اشکال (bugreport) چندین جدول زمانی موازی را منعکس می‌کند: گزارش سیستم، گزارش رویداد، گزارش هسته و چندین جدول زمانی تخصصی برای پخش‌ها، آمار باتری و غیره. متأسفانه، جدول‌های زمانی اغلب با استفاده از پایگاه‌های زمانی مختلف گزارش می‌شوند.

مهرهای زمانی سیستم و گزارش رویداد (مانند اکثر مهرهای زمانی دیگر) در همان منطقه زمانی کاربر هستند. برای مثال، وقتی کاربر دکمه خانه را فشار می‌دهد، گزارش سیستم به صورت زیر گزارش می‌شود:

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

در مرحله بعد، مهرهای زمانی لاگ هسته ( dmesg ) را برای پیام Starting service 'bugreport' بررسی کنید:

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

برای مرتبط کردن دو رویداد، به عقب برگردید و نکات ذکر شده در همگام‌سازی جدول زمانی را در نظر داشته باشید. اگرچه پس از شروع گزارش اشکال، اتفاقات زیادی رخ می‌دهد، اما بیشتر فعالیت‌ها چندان مفید نیستند زیرا عمل دریافت گزارش اشکال، سیستم را به میزان قابل توجهی بارگذاری می‌کند.

قدرت

گزارش رویدادها شامل وضعیت روشن بودن صفحه نمایش است که در آن عدد ۰ به معنای خاموش بودن صفحه نمایش، عدد ۱ به معنای روشن بودن صفحه نمایش و عدد ۲ به معنای انجام شدن عملیات محافظت از صفحه کلید است.

گزارش‌های اشکال همچنین شامل آماری در مورد قفل‌های بیدارباش هستند، مکانیزمی که توسط توسعه‌دهندگان برنامه برای نشان دادن نیاز برنامه‌شان به روشن ماندن دستگاه استفاده می‌شود. (برای جزئیات بیشتر در مورد قفل‌های بیدارباش، به PowerManager.WakeLock و Keep the CPU on مراجعه کنید.)

آمار تجمیعی مدت زمان قفل بیداری تنها زمانی را که یک قفل بیداری واقعاً مسئول بیدار نگه داشتن دستگاه است، ردیابی می‌کند و زمان روشن بودن صفحه نمایش را شامل نمی‌شود . علاوه بر این، اگر چندین قفل بیداری به طور همزمان فعال باشند، مدت زمان قفل بیداری بین آن قفل‌های بیداری توزیع می‌شود.

برای کمک بیشتر در تجسم وضعیت باتری، از Battery Historian ، یک ابزار متن‌باز گوگل برای تجزیه و تحلیل مصرف‌کنندگان باتری با استفاده از فایل‌های گزارش اشکال اندروید، استفاده کنید.

بسته‌ها

بخش DUMP OF SERVICE package شامل نسخه‌های برنامه (و سایر اطلاعات مفید) است.

فرآیندها

گزارش‌های باگ حاوی حجم عظیمی از داده‌ها برای فرآیندها، از جمله زمان شروع و توقف، طول زمان اجرا، سرویس‌های مرتبط، امتیاز oom_adj و غیره هستند. برای جزئیات بیشتر در مورد نحوه مدیریت فرآیندها توسط اندروید، به Processes and Threads مراجعه کنید.

تعیین زمان اجرای فرآیند

بخش procstats شامل آمار کاملی در مورد مدت زمان اجرای فرآیندها و سرویس‌های مرتبط است. برای مشاهده خلاصه‌ای سریع و خوانا برای انسان، عبارت AGGREGATED OVER را جستجو کنید تا داده‌های سه یا ۲۴ ساعت گذشته را مشاهده کنید، سپس Summary: را جستجو کنید تا لیست فرآیندها، مدت زمان اجرای این فرآیندها با اولویت‌های مختلف و میزان استفاده از RAM آنها که به صورت min-average-max PSS/min-average-max USS فرمت‌بندی شده است را مشاهده کنید.

دلایل اجرای یک فرآیند

بخش dumpsys activity processes تمام فرآیندهای در حال اجرا را که بر اساس امتیاز oom_adj مرتب شده‌اند، فهرست می‌کند (اندروید اهمیت فرآیند را با اختصاص مقدار 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 است.

  • برای شناسایی برنامه‌ی مسئول، نام بسته را در گوگل پلی جستجو کنید: https://play.google.com/store/apps/details?id=com.badapp .

توجه : برای دستگاه‌هایی که اندروید ۷.۰ را اجرا می‌کنند، سیستم داده‌ها را برای اسکن‌های BLE جمع‌آوری می‌کند و این فعالیت‌ها را با برنامه‌ی آغازین مرتبط می‌کند. برای جزئیات بیشتر، به اسکن‌های کم‌مصرف (LE) و بلوتوث مراجعه کنید.