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

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

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

Logcat

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

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

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

سطوح گزارش شامل موارد زیر است:

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

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

ANR ها و بن بست ها

گزارش‌های اشکال می‌توانند به شما کمک کنند تا بفهمید چه چیزی باعث خطاهای Application Not Responding (ANR) و رویدادهای بن بست می‌شود.

شناسایی برنامه های غیر پاسخگو

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

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

یافتن رد پشته

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

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

یافتن بن بست ها

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

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

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

فعالیت ها

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

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

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

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

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

آیا دستگاه کوبنده است؟

برای تعیین اینکه آیا دستگاه در حال am_proc_died و am_proc_start در مدت زمان کوتاهی بررسی کنید.

حافظه

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

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

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

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

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

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

مشاهده شاخص های کوبیدن

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

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

گرفتن عکس لحظه ای حافظه

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

پخش می شود

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

مشاهده برنامه های تاریخی

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

بخش خلاصه مروری بر 300 آخرین پخش پیش زمینه و 300 آخرین پخش پس زمینه است.

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

  • ورودی BroadcastFilter در زمان اجرا ثبت می شود و فقط به فرآیندهای در حال اجرا ارسال می شود.
  • ورودی ResolveInfo از طریق ورودی های مانیفست ثبت می شود. ActivityManager فرآیند را برای هر ResolveInfo در صورتی که قبلاً اجرا نشده است شروع می کند.

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

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

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

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

گردآوری پس زمینه

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

هنگام بارگیری به‌روزرسانی‌های فروشگاه Google Play، ممکن است گردآوری در پس‌زمینه رخ دهد. در این مورد، پیام‌های برنامه فروشگاه Google Play ( 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 ) از یک پایگاه زمانی متفاوت استفاده می‌کنند و آیتم‌های گزارش را با چند ثانیه پس از اتمام بوت‌لودر برچسب‌گذاری می‌کنند. برای ثبت این بازه زمانی در سایر مقیاس‌های زمانی، پیام‌های 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'...

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

قدرت

گزارش رویداد حاوی وضعیت برق صفحه است، که در آن 0 صفحه نمایش خاموش، 1 صفحه نمایش روشن، و 2 برای صفحه کلید تمام شده است.

گزارش‌های باگ همچنین حاوی آماری درباره wake lock هستند، مکانیزمی که توسط توسعه‌دهندگان برنامه برای نشان دادن نیازهای برنامه‌شان به روشن ماندن دستگاه استفاده می‌شود. (برای جزئیات بیشتر در مورد wake lock، به PowerManager.WakeLock مراجعه کنید و CPU را روشن نگه دارید .)

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

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

بسته ها

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

فرآیندها

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

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

بخش procstats حاوی آمار کاملی از مدت زمان اجرای فرآیندها و خدمات مرتبط است. برای خلاصه‌ای سریع و قابل خواندن برای انسان، AGGREGATED OVER را جستجو کنید تا داده‌های سه یا 24 ساعت گذشته را مشاهده کنید، سپس Summary: فهرستی از فرآیندها، مدت زمانی که آن فرآیندها در اولویت‌های مختلف اجرا شده‌اند و RAM آنها. فرمت استفاده به صورت حداقل میانگین حداکثر PSS/حداکثر میانگین حداکثر 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 است.

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

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