קריאת דוחות באגים

באגים הם מציאות בכל סוג של פיתוח - ודוחות באגים הם קריטיים לזיהוי ופתרון בעיות. כל הגרסאות של Android תומכות בלכידת דוחות באגים עם Android Debug Bridge (adb) ; גרסאות אנדרואיד 4.2 ומעלה תומכות באפשרות למפתחים עבור קבלת דוחות באגים ושיתוף באמצעות דואר אלקטרוני, Drive וכו'.

דוחות באגים של Android מכילים נתוני dumpsys , dumpstate ו- logcat בפורמט טקסט (.txt), המאפשרים לך לחפש בקלות תוכן ספציפי. הסעיפים הבאים מפרטים רכיבים של דוחות באגים, מתארים בעיות נפוצות ומעניקים עצות מועילות ופקודות grep למציאת יומנים הקשורים לאותם באגים. רוב הסעיפים כוללים גם דוגמאות לפקודת grep ופלט ו/או פלט dumpsys .

Logcat

יומן ה- logcat הוא dump מבוסס-מחרוזת של כל מידע ה- logcat . חלק המערכת שמור למסגרת ויש לו היסטוריה ארוכה יותר מהראשית שמכילה את כל השאר. כל שורה מתחילה בדרך כלל עם timestamp UID PID TID log-level , אם כי ייתכן שה- UID לא מופיע בגרסאות ישנות יותר של Android.

צפייה ביומן האירועים

יומן זה מכיל ייצוגי מחרוזת של הודעות יומן בפורמט בינארי. זה פחות רועש מהיומן של logcat אבל גם קצת יותר קשה לקריאה. בעת הצגת יומני אירועים, אתה יכול לחפש בקטע זה מזהה תהליך ספציפי (PID) כדי לראות מה תהליך עשה. הפורמט הבסיסי הוא: timestamp PID TID log-level log-tag tag-values .

רמות היומן כוללות את הדברים הבאים:

  • V: מילולית
  • D: איתור באגים
  • אני: מידע
  • W: אזהרה
  • ה: שגיאה

לתגים שימושיים אחרים של יומן אירועים, עיין ב/services/core/java/com/android/server/ EventLogTags.logtags .

ANRs ומבוי סתום

דיווחי באגים יכולים לעזור לך לזהות מה גורם לשגיאות Application Not Responsing (ANR) ולאירועי מבוי סתום.

זיהוי אפליקציות שאינן מגיבות

כאשר אפליקציה לא מגיבה תוך זמן מסוים, בדרך כלל בגלל שרשור ראשי חסום או תפוס, המערכת הורגת את התהליך ומשליכה את המחסנית אל /data/anr . כדי לגלות את האשם מאחורי ANR, grep עבור am_anr ביומן האירועים הבינארי.

אתה יכול גם להזין grep עבור ANR in ביומן logcat , המכיל מידע נוסף על מה שעשה שימוש ב-CPU בזמן ה-ANR.

מציאת עקבות מחסנית

לעתים קרובות אתה יכול למצוא עקבות מחסנית התואמות ל-ANR. ודא שחותמת הזמן וה-PID על עקבות ה-VM תואמים ל-ANR שאתה חוקר, ולאחר מכן בדוק את השרשור הראשי של התהליך. זכור:

  • השרשור הראשי אומר לך רק מה השרשור עשה בזמן ה-ANR, מה שעשוי להתאים או לא לגורם האמיתי ל-ANR. (המחסנית בדוח הבאג עשויה להיות תמימה; ייתכן שמשהו אחר נתקע במשך זמן רב - אבל לא מספיק זמן ל-ANR - לפני שהתנתק.)
  • ייתכן שתתקיים יותר מקבוצה אחת של עקבות מחסנית ( VM TRACES JUST NOW ו- VM TRACES AT LAST ANR ). ודא שאתה צופה בקטע הנכון.

מציאת מבוי סתום

מבוי סתום מופיע לעתים קרובות לראשונה כ-ANR כי שרשורים נתקעים. אם הקיפאון פוגע בשרת המערכת, כלב השמירה בסופו של דבר יהרוג אותו, מה שיוביל לרישום ביומן הדומה ל: WATCHDOG KILLING SYSTEM PROCESS . מנקודת המבט של המשתמש, המכשיר מאתחל, אם כי מבחינה טכנית מדובר בהפעלה מחדש בזמן ריצה ולא באתחול אמיתי.

  • בהפעלה מחדש של זמן ריצה , שרת המערכת מת ומופעל מחדש; המשתמש רואה את המכשיר חוזר להנפשת האתחול.
  • באתחול מחדש , הקרנל קרס; המשתמש רואה את המכשיר חוזר ללוגו האתחול של Google.

כדי למצוא מבוי סתום, בדוק במקטעים של מעקבי VM עבור תבנית של חוט A ממתין על משהו המוחזק על ידי חוט B, שבתורו ממתין על משהו המוחזק על ידי חוט A.

פעילויות

פעילות היא רכיב יישום המספק מסך שמשתמשים מקיימים איתו אינטראקציה כדי לעשות משהו כמו לחייג מספר, לצלם תמונה, לשלוח מייל וכו'. מנקודת מבט של דיווח באג, פעילות היא דבר יחיד וממוקד שמשתמש יכול לעשות , מה שהופך את איתור הפעילות שהייתה במוקד במהלך התרסקות חשוב מאוד. פעילויות (באמצעות ActivityManager) מריצים תהליכים, כך שאיתור כל עצירות והתחלות התהליך עבור פעילות נתונה יכול גם לסייע בפתרון בעיות.

צפייה בפעילויות ממוקדות

כדי להציג היסטוריה של פעילויות ממוקדות, חפש am_focused_activity .

תהליך הצפייה מתחיל

כדי להציג היסטוריה של התחלות תהליכים, חפש את Start proc תהליך .

המכשיר דופק?

כדי לקבוע אם המכשיר דופק , בדוק אם יש עלייה חריגה בפעילות סביב am_proc_died ו- am_proc_start תוך פרק זמן קצר.

זיכרון

מכיוון שלמכשירי אנדרואיד יש לעתים קרובות זיכרון פיזי מוגבל, ניהול זיכרון גישה אקראית (RAM) הוא קריטי. דוחות באגים מכילים מספר אינדיקטורים של זיכרון נמוך וכן מצב dump המספק תמונת מצב של זיכרון.

זיהוי זיכרון נמוך

זיכרון נמוך עלול לגרום למערכת להרוס כיוון שהיא הורגת תהליכים מסוימים כדי לשחרר זיכרון אך ממשיכה להתחיל תהליכים אחרים. כדי לראות עדויות מאששות של זיכרון נמוך, בדוק אם יש ריכוזים של ערכי am_proc_died ו- am_proc_start ביומן האירועים הבינארי.

זיכרון נמוך יכול גם להאט את החלפת המשימות ולסכל ניסיונות החזרה (מכיוון שהמשימה שהמשתמש ניסה לחזור אליה נהרגה). אם המשגר ​​נהרג, הוא מופעל מחדש כאשר המשתמש נוגע בכפתור הבית והיומנים מראים שהמשגר ​​טוען מחדש את התוכן שלו.

צפייה באינדיקטורים היסטוריים

הערך am_low_memory ביומן האירועים הבינארי מציין שהתהליך האחרון המאוחסן במטמון מת. לאחר מכן, המערכת מתחילה להרוג שירותים.

צפייה באינדיקטורים של חבטות

אינדיקטורים אחרים למחיקה של המערכת (החלפה, החזרה ישירה וכו') כוללים מחזורי צריכה של kswapd , kworker ו- mmcqd . (זכור שדוח הבאג שנאסף יכול להשפיע על אינדיקטורים לחבטות.)

יומני ANR יכולים לספק תמונת מצב דומה של זיכרון.

קבלת תמונת מצב זיכרון

תמונת המצב של הזיכרון היא מצב dump המפרט תהליכים שפועלים ב-Java ומקוריים (לפרטים, עיין בהצגת הקצאות זיכרון כוללות). זכור שתמונת המצב נותנת רק את המצב ברגע מסוים בזמן; ייתכן שהמערכת הייתה במצב טוב יותר (או גרוע יותר) לפני תמונת המצב.

שידורים

יישומים מייצרים שידורים כדי לשלוח אירועים בתוך האפליקציה הנוכחית או לאפליקציה אחרת. מקלטי שידור נרשמים להודעות ספציפיות (באמצעות מסננים), ומאפשרים להם גם להאזין וגם להגיב לשידור. דיווחי באגים מכילים מידע על שידורים שנשלחו ושידורים שלא נשלחו, כמו גם דיווח של כל המקלטים שמאזינים לשידור ספציפי.

צפייה בשידורים היסטוריים

שידורים היסטוריים הם אלה שכבר נשלחו, הרשומים בסדר כרונולוגי הפוך.

קטע הסיכום הוא סקירה של 300 שידורי החזית האחרונים ו-300 שידורי הרקע האחרונים.

קטע הפירוט מכיל מידע מלא עבור 50 שידורי החזית האחרונים ו-50 שידורי הרקע האחרונים, וכן את המקלטים עבור כל שידור. מקלטים שיש להם:

  • רשומות BroadcastFilter נרשמות בזמן ריצה ונשלחות רק לתהליכים שכבר פועלים.
  • רשומת ResolveInfo נרשמה דרך ערכי מניפסט. ActivityManager מתחיל את התהליך עבור כל ResolveInfo אם הוא עדיין לא פועל.

צפייה בשידורים פעילים

שידורים פעילים הם אלה שטרם נשלחו. מספר גדול בתור אומר שהמערכת לא יכולה לשלוח את השידורים מהר מספיק כדי לעמוד בקצב.

צפייה במאזיני שידורים

לצפייה ברשימה של מקלטים שמאזינים לשידור, בדוק את טבלת ה-Resolver Receiver 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]

יומני 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

מכיוון שייתכן שיומני הקרנל לא יכללו זמן בזמן ההשעיה, עליך לרשום את היומן באופן חלקי בין הודעת הכניסה והיציאה של ההשעיה. בנוסף, יומני הקרנל משתמשים באזור זמן 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 הוא עבור מקשים שנעשו.

דיווחי באגים מכילים גם נתונים סטטיסטיים על נעילות התעוררות, מנגנון המשמש מפתחי אפליקציות כדי לציין את צרכי האפליקציה שלהם כדי שהמכשיר יישאר דלוק. (לפרטים על נעילות התעוררות, עיין ב- PowerManager.WakeLock ושמור את המעבד פועל .)

הסטטיסטיקה המצטברת של משך נעילת התעוררות עוקבת רק אחר הזמן שבו נעילת התעוררות אחראית למעשה לשמירה על ערנות המכשיר ואינה כוללת זמן כשהמסך פועל. בנוסף, אם מספר נעילות השכמה מוחזקים בו-זמנית, משך נעילת ההתעוררות מתחלק על פני אותם מנעולים.

לעזרה נוספת בהצגה של מצב הספק, השתמש ב- Battery Historian , כלי קוד פתוח של Google לניתוח צרכני סוללה באמצעות קובצי דיווח באגים של Android.

חבילות

סעיף DUMP OF SERVICE package מכיל גרסאות אפליקציה (ומידע שימושי אחר).

תהליכים

דוחות באגים מכילים כמות עצומה של נתונים עבור תהליכים, כולל זמן התחלה ועצירה, אורך זמן ריצה, שירותים משויכים, ציון oom_adj וכו'. לפרטים על האופן שבו אנדרואיד מנהלת תהליכים, עיין בתהליכים ונשושים .

קביעת זמן ריצה של תהליך

קטע ה- procstats מכיל נתונים סטטיסטיים מלאים על משך הזמן שהתהליכים והשירותים הנלווים פועלים. לסיכום מהיר וניתן לקריאה אנושית, חפש את AGGREGATED OVER כדי להציג נתונים משלוש או 24 השעות האחרונות, ולאחר מכן חפש את Summary: כדי להציג את רשימת התהליכים, כמה זמן תהליכים אלה פעלו בסדרי עדיפויות שונים ו-RAM שלהם. שימוש מעוצב כ-min-average-max PSS/min-average-max USS.

מדוע פועל תהליך?

סעיף dumpsys activity processes של dumpsys מפרט את כל התהליכים הפועלים כעת לפי ציון oom_adj (אנדרואיד מציין את חשיבות התהליך על ידי הקצאת לתהליך ערך oom_adj , שניתן לעדכן באופן דינמי על ידי ActivityManager). הפלט דומה לזה של תמונת מצב של זיכרון אך כולל מידע נוסף על מה שגורם לתהליך לפעול. בדוגמה שלהלן, הערכים המודגשים מציינים שהתהליך gms.persistent פועל בעדיפות vis (גלוי) מכיוון שתהליך המערכת קשור ל- NetworkLocationService שלו.

סריקות

השתמש בשלבים הבאים כדי לזהות יישומים המבצעים סריקות מוגזמות של Bluetooth Low Energy (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 .

הערה : עבור מכשירים המריצים אנדרואיד 7.0, המערכת אוספת נתונים עבור סריקות BLE ומשייכת פעילויות אלו לאפליקציה המתחילה. לפרטים, ראה סריקות באנרגיה נמוכה (LE) ו-Bluetooth .