قراءة تقارير الأخطاء

تعد الأخطاء أمرًا واقعيًا في أي نوع من التطوير - وتعد تقارير الأخطاء أمرًا بالغ الأهمية لتحديد المشكلات وحلها. تدعم جميع إصدارات Android التقاط تقارير الأخطاء باستخدام Android Debug Bridge (adb) ؛ تدعم إصدارات Android 4.2 والإصدارات الأحدث خيار المطور لأخذ تقارير الأخطاء ومشاركتها عبر البريد الإلكتروني و Drive وما إلى ذلك.

تحتوي تقارير أخطاء Android على dumpsys و dumpstate و logcat بتنسيق نصي (.txt) ، مما يتيح لك البحث بسهولة عن محتوى معين. توضح الأقسام التالية بالتفصيل مكونات تقرير الأخطاء ، وتصف المشكلات الشائعة ، وتقدم نصائح مفيدة وأوامر grep للعثور على السجلات المرتبطة بهذه الأخطاء. تتضمن معظم الأقسام أيضًا أمثلة لأمر grep والإخراج و / أو إخراج dumpsys .

لوجكات

سجل logcat هو تفريغ مستند إلى سلسلة لجميع معلومات logcat . جزء النظام محجوز للإطار وله تاريخ أطول من الرئيسي الذي يحتوي على كل شيء آخر. يبدأ كل سطر عادةً timestamp UID PID TID log-level ، على الرغم من أن UID قد لا يكون مدرجًا في الإصدارات الأقدم من Android.

عرض سجل الأحداث

يحتوي هذا السجل على تمثيلات سلسلة لرسائل السجل ذات التنسيق الثنائي. إنه أقل ضوضاء من سجل logcat ولكنه أيضًا أصعب قليلاً في القراءة. عند عرض سجلات الأحداث ، يمكنك البحث في هذا القسم عن معرّف عملية معين (PID) لمعرفة ما تقوم به العملية. التنسيق الأساسي هو: timestamp PID TID log-level log-tag tag-values .

تشمل مستويات السجل ما يلي:

  • الخامس: مطول
  • D: التصحيح
  • أنا: معلومات
  • W: تحذير
  • ه: خطأ

للتعرف على علامات سجل الأحداث المفيدة الأخرى ، ارجع إلى /services/core/java/com/android/server/EventLogTags.logtags .

أخطاء ANR والمآزق

يمكن أن تساعدك تقارير الأخطاء في تحديد أسباب حدوث أخطاء التطبيق لا يستجيب (ANR) وأحداث الجمود.

تحديد التطبيقات غير المستجيبة

عندما لا يستجيب أحد التطبيقات خلال فترة زمنية معينة ، عادةً بسبب وجود مؤشر ترابط رئيسي محظور أو مشغول ، فإن النظام يقتل العملية ويفريغ المكدس إلى /data/anr . لاكتشاف الجاني وراء ANR ، استخدم grep لـ am_anr في سجل الأحداث الثنائي.

يمكنك أيضًا إدخال grep لـ ANR in سجل logcat ، والذي يحتوي على مزيد من المعلومات حول ما كان يستخدم وحدة المعالجة المركزية في وقت ANR.

البحث عن آثار المكدس

يمكنك غالبًا العثور على تتبعات المكدس التي تتوافق مع ANR. تأكد من تطابق الطابع الزمني و PID على تتبع الجهاز الظاهري مع ANR الذي تبحث عنه ، ثم تحقق من السلسلة الرئيسية للعملية. تذكر:

  • يخبرك الخيط الرئيسي فقط بما كان يفعله مؤشر الترابط في وقت ANR ، والذي قد يتوافق أو لا يتوافق مع السبب الحقيقي لـ ANR. (قد تكون الحزمة في تقرير الخطأ بريئة ؛ ربما يكون هناك شيء آخر عالق لفترة طويلة - ولكن ليس بالقدر الكافي لـ ANR - قبل أن يصبح غير عالق.)
  • قد توجد أكثر من مجموعة واحدة من تتبعات المكدس ( VM TRACES JUST NOW و VM TRACES AT LAST ANR ). تأكد من عرض القسم الصحيح.

إيجاد المآزق

غالبًا ما تظهر حالات deadlocks أولاً على أنها أخطاء ANR لأن سلاسل المحادثات تتعطل. إذا وصل الجمود إلى خادم النظام ، فإن المراقبة ستقضي عليه في النهاية ، مما يؤدي إلى إدخال في السجل مشابه لـ: WATCHDOG KILLING SYSTEM PROCESS . من وجهة نظر المستخدم ، يتم إعادة تشغيل الجهاز ، على الرغم من أن هذا من الناحية الفنية هو إعادة تشغيل وقت التشغيل وليس إعادة تشغيل حقيقية.

  • في إعادة تشغيل وقت التشغيل ، يموت خادم النظام ويتم إعادة تشغيله ؛ يرى المستخدم الجهاز يعود إلى الرسوم المتحركة التمهيد.
  • في إعادة التشغيل ، تحطمت النواة ؛ يرى المستخدم الجهاز يعود إلى شعار تشغيل Google.

للعثور على حالات توقف تام ، تحقق من أقسام تتبع VM لنمط الخيط A الذي ينتظر شيئًا ممسوكًا بواسطة الخيط 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 لقطة ذاكرة مشابهة.

الحصول على لقطة من الذاكرة

لقطة الذاكرة هي حالة تفريغ تسرد عمليات تشغيل Java والعمليات الأصلية (للحصول على التفاصيل ، راجع عرض مخصصات الذاكرة الإجمالية ). ضع في اعتبارك أن اللقطة تعطي الحالة فقط في لحظة معينة من الزمن ؛ قد يكون النظام في حالة أفضل (أو أسوأ) قبل اللقطة.

البث

تنشئ التطبيقات عمليات بث لإرسال الأحداث داخل التطبيق الحالي أو إلى تطبيق آخر. يشترك مُستقبلو البث في رسائل محددة (عبر المرشحات) ، مما يمكنهم من الاستماع والرد على البث. تحتوي تقارير الأخطاء على معلومات حول عمليات البث المرسلة وعمليات البث غير المرسلة ، بالإضافة إلى عمليات تفريغ لجميع أجهزة الاستقبال التي تستمع إلى بث معين.

مشاهدة البث التاريخي

عمليات البث التاريخية هي تلك التي تم إرسالها بالفعل ، وهي مدرجة بترتيب زمني عكسي.

قسم الملخص هو نظرة عامة على آخر 300 بث أمامي وآخر 300 بث في الخلفية.

يحتوي قسم التفاصيل على معلومات كاملة لآخر 50 بثًا أماميًا وآخر 50 بثًا في الخلفية ، بالإضافة إلى أجهزة الاستقبال لكل بث. أجهزة الاستقبال التي تحتوي على:

  • يتم تسجيل إدخال 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. في هذه الحالة ، تظهر الرسائل من تطبيق متجر Google Play ( finsky ) dex2oat installd

قد يحدث التجميع أيضًا في الخلفية عندما يقوم أحد التطبيقات بتحميل ملف 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]

تستخدم سجلات Kernel ( 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

نظرًا لأن سجلات kernel قد لا تتضمن الوقت أثناء التوقف المرحلي ، يجب عليك تسجيل السجل بطريقة متعددة المستويات بين رسائل الإدخال والإخراج. بالإضافة إلى ذلك ، تستخدم سجلات kernel المنطقة الزمنية UTC ويجب تعديلها وفقًا للمنطقة الزمنية للمستخدم.

تحديد وقت تقرير الخطأ

لتحديد وقت أخذ تقرير الخطأ ، تحقق أولاً من سجل النظام (Logcat) لحالة dumpstate: begin :

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

بعد ذلك ، تحقق من الطوابع الزمنية لسجل kernel ( dmesg ) لرسالة Starting service 'bugreport' :

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

اعمل بشكل عكسي لربط الحدثين ، مع مراعاة التحذيرات المذكورة في الجداول الزمنية للمزامنة . بينما يحدث الكثير بعد بدء تقرير الخطأ ، فإن معظم الأنشطة ليست مفيدة جدًا لأن أخذ تقرير الخطأ يؤدي إلى تحميل النظام بشكل كبير.

سلطة

يحتوي سجل الأحداث على حالة طاقة الشاشة ، حيث يكون 0 مغلقًا ، و 1 قيد التشغيل ، و 2 لحارس المفاتيح تم إنجازه.

تحتوي تقارير الأخطاء أيضًا على إحصائيات حول أقفال التنبيه ، وهي آلية يستخدمها مطورو التطبيقات للإشارة إلى أن تطبيقهم يحتاج إلى بقاء الجهاز قيد التشغيل. (للحصول على تفاصيل حول أقفال التنبيه ، راجع PowerManager.WakeLock واحتفظ بوحدة المعالجة المركزية قيد التشغيل .)

لا تتعقب إحصائيات مدة قفل الاستيقاظ المجمعة سوى الوقت الذي يكون فيه قفل التنبيه مسؤولاً فعليًا عن إبقاء الجهاز مستيقظًا ولا تتضمن الوقت الذي تكون فيه الشاشة قيد التشغيل. بالإضافة إلى ذلك ، إذا تم تعليق العديد من أقفال التنبيه في وقت واحد ، فسيتم توزيع وقت مدة قفل التنبيه عبر أقفال التنبيه هذه.

لمزيد من المساعدة في تصور حالة الطاقة ، استخدم Battery Historyian ، وهي أداة مفتوحة المصدر من Google لتحليل مستهلكي البطارية باستخدام ملفات تقرير أخطاء Android.

الحزم

يحتوي قسم DUMP OF SERVICE package على إصدارات التطبيق (ومعلومات مفيدة أخرى).

العمليات

تحتوي تقارير الأخطاء على قدر هائل من البيانات للعمليات ، بما في ذلك وقت البدء والإيقاف ، وطول وقت التشغيل ، والخدمات المرتبطة ، ودرجة oom_adj ، وما إلى ذلك. للحصول على تفاصيل حول كيفية إدارة Android للعمليات ، راجع العمليات والخيوط.

تحديد وقت تشغيل العملية

يحتوي قسم procstats على إحصائيات كاملة حول مدة تشغيل العمليات والخدمات المرتبطة بها. للحصول على ملخص سريع يمكن قراءته من قبل الإنسان ، ابحث عن AGGREGATED OVER لعرض البيانات من آخر ثلاث أو 24 ساعة ، ثم ابحث عن Summary: لعرض قائمة العمليات ، ومدة تشغيل هذه العمليات وفقًا للأولويات المختلفة ، وذاكرة الوصول العشوائي الخاصة بهم تم تنسيق الاستخدام كـ min-average-max PSS / min-average-max 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
    
  • حدد موقع معرف المنتج في رسائل السجل. في هذا المثال ، "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) والبلوتوث .