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

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

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

Logcat

لاگ logcat یک تخلیه مبتنی بر رشته از تمام اطلاعات logcat است. بخش سیستم برای چارچوب رزرو شده است و تاریخچه طولانی تری نسبت به اصلی دارد که شامل همه چیزهای دیگر است. هر خط معمولاً با 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 نگهداری می‌شود.

فعالیت ها

اکتیویتی جزء برنامه‌ای است که به کاربران صفحه‌نمایش را برای انجام کاری مانند شماره‌گیری، عکس گرفتن، ارسال ایمیل و غیره فراهم می‌کند. ، که مکان یابی فعالیتی را که در حین تصادف در کانون توجه بوده است بسیار مهم می کند. فعالیت‌ها (از طریق 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) و بلوتوث مراجعه کنید.