Đọc báo cáo lỗi

Lỗi là một thực tế trong bất kỳ loại hình phát triển nào—và báo cáo lỗi rất quan trọng để xác định và giải quyết vấn đề. Tất cả các phiên bản Android đều hỗ trợ ghi lại báo cáo lỗi bằng Cầu gỡ lỗi Android (adb) ; Phiên bản Android 4.2 trở lên hỗ trợ Tùy chọn nhà phát triển để nhận báo cáo lỗi và chia sẻ qua email, Drive, v.v.

Báo cáo lỗi của Android chứa dữ liệu dumpsys , dumpstatelogcat ở định dạng văn bản (.txt), cho phép bạn dễ dàng tìm kiếm nội dung cụ thể. Các phần sau đây trình bày chi tiết các thành phần báo cáo lỗi, mô tả các sự cố thường gặp và đưa ra các mẹo hữu ích cũng như lệnh grep để tìm nhật ký liên quan đến các lỗi đó. Hầu hết các phần cũng bao gồm các ví dụ về lệnh grep và đầu ra và/hoặc đầu ra dumpsys .

logcat

Nhật ký logcat là kết xuất dựa trên chuỗi của tất cả thông tin logcat . Phần hệ thống được dành riêng cho khung và có lịch sử lâu hơn phần chính chứa mọi thứ khác. Mỗi dòng thường bắt đầu bằng timestamp UID PID TID log-level , mặc dù UID có thể không được liệt kê trong các phiên bản Android cũ hơn.

Xem nhật ký sự kiện

Nhật ký này chứa các biểu diễn chuỗi của thông điệp tường trình có định dạng nhị phân. Nó ít ồn hơn nhật ký logcat nhưng cũng khó đọc hơn một chút. Khi xem nhật ký sự kiện, bạn có thể tìm kiếm ID quy trình cụ thể (PID) trong phần này để xem quy trình đang thực hiện những gì. Định dạng cơ bản là: timestamp PID TID log-level log-tag tag-values ​​.

Các cấp độ nhật ký bao gồm:

  • V: dài dòng
  • D: gỡ lỗi
  • Tôi: thông tin
  • W: cảnh báo
  • Đ: lỗi

Để biết các thẻ nhật ký sự kiện hữu ích khác, hãy tham khảo /services/core/java/com/android/server/EventLogTags.logtags .

ANR và bế tắc

Báo cáo lỗi có thể giúp bạn xác định nguyên nhân gây ra lỗi Ứng dụng không phản hồi (ANR) và các sự kiện bế tắc.

Xác định các ứng dụng không phản hồi

Khi một ứng dụng không phản hồi trong một thời gian nhất định, thường là do luồng chính bị chặn hoặc bận, hệ thống sẽ tắt tiến trình và chuyển ngăn xếp vào /data/anr . Để khám phá thủ phạm đằng sau ANR, hãy grep for am_anr trong nhật ký sự kiện nhị phân.

Bạn cũng có thể grep tìm ANR in nhật ký logcat , nhật ký này chứa nhiều thông tin hơn về những gì đang sử dụng CPU tại thời điểm xảy ra ANR.

Tìm dấu vết ngăn xếp

Bạn thường có thể tìm thấy dấu vết ngăn xếp tương ứng với ANR. Đảm bảo dấu thời gian và PID trên dấu vết VM khớp với ANR mà bạn đang điều tra, sau đó kiểm tra luồng chính của quy trình. Ghi nhớ:

  • Chuỗi chính chỉ cho bạn biết chuỗi đang thực hiện những gì tại thời điểm xảy ra ANR, điều này có thể tương ứng hoặc không tương ứng với nguyên nhân thực sự của ANR. (Ngăn xếp trong báo cáo lỗi có thể vô hại; nội dung nào đó khác có thể đã bị kẹt trong một thời gian dài—nhưng không đủ lâu để xảy ra ANR—trước khi được gỡ bỏ.)
  • Có thể tồn tại nhiều tập hợp dấu vết ngăn xếp ( VM TRACES JUST NOWVM TRACES AT LAST ANR ). Hãy chắc chắn rằng bạn đang xem đúng phần.

Tìm bế tắc

Bế tắc thường xuất hiện đầu tiên dưới dạng ANR vì các luồng đang bị kẹt. Nếu bế tắc xảy ra với máy chủ hệ thống, cơ quan giám sát cuối cùng sẽ tiêu diệt nó, dẫn đến một mục trong nhật ký tương tự như: WATCHDOG KILLING SYSTEM PROCESS . Từ góc độ người dùng, thiết bị sẽ khởi động lại, mặc dù về mặt kỹ thuật, đây là lần khởi động lại trong thời gian chạy chứ không phải là khởi động lại thực sự.

  • Khi khởi động lại thời gian chạy , máy chủ hệ thống sẽ ngừng hoạt động và được khởi động lại; người dùng thấy thiết bị quay trở lại hoạt ảnh khởi động.
  • Khi khởi động lại , kernel đã bị hỏng; người dùng thấy thiết bị quay trở lại logo khởi động của Google.

Để tìm các bế tắc, hãy kiểm tra các phần theo dõi VM để tìm mẫu luồng A đang chờ trên thứ gì đó được giữ bởi luồng B, đến lượt nó đang chờ trên thứ gì đó được giữ bởi luồng A.

Các hoạt động

Hoạt động là một thành phần ứng dụng cung cấp màn hình mà người dùng tương tác để thực hiện một số việc như quay số, chụp ảnh, gửi email, v.v. Từ góc độ báo cáo lỗi, hoạt động là một việc duy nhất, tập trung mà người dùng có thể thực hiện , điều này làm cho việc định vị hoạt động được chú ý trong vụ tai nạn trở nên rất quan trọng. Các hoạt động (thông qua Trình quản lý hoạt động) chạy các quy trình, do đó, việc xác định tất cả các điểm dừng và bắt đầu của quy trình cho một hoạt động nhất định cũng có thể hỗ trợ khắc phục sự cố.

Xem các hoạt động tập trung

Để xem lịch sử các hoạt động tập trung, hãy tìm kiếm am_focused_activity .

Quá trình xem bắt đầu

Để xem lịch sử bắt đầu quá trình, hãy tìm kiếm Start proc .

Xác định xem thiết bị có bị giật không

Để xác định xem thiết bị có bị hỏng hay không , hãy kiểm tra xem hoạt động có tăng bất thường xung quanh am_proc_diedam_proc_start trong một khoảng thời gian ngắn hay không.

Ký ức

Vì các thiết bị Android thường có bộ nhớ vật lý hạn chế nên việc quản lý bộ nhớ truy cập ngẫu nhiên (RAM) là rất quan trọng. Báo cáo lỗi chứa một số chỉ báo về bộ nhớ thấp cũng như trạng thái kết xuất cung cấp ảnh chụp nhanh bộ nhớ.

Xác định bộ nhớ thấp

Bộ nhớ thấp có thể khiến hệ thống gặp sự cố vì nó giết một số tiến trình để giải phóng bộ nhớ nhưng vẫn tiếp tục khởi động các tiến trình khác. Để xem bằng chứng chứng thực về tình trạng bộ nhớ thấp, hãy kiểm tra nồng độ của các mục am_proc_diedam_proc_start trong nhật ký sự kiện nhị phân.

Bộ nhớ thấp cũng có thể làm chậm quá trình chuyển đổi tác vụ và cản trở các nỗ lực quay lại (vì tác vụ mà người dùng đang cố gắng quay lại đã bị hủy). Nếu trình khởi chạy bị tắt, trình khởi chạy sẽ khởi động lại khi người dùng chạm vào nút trang chủ và nhật ký hiển thị trình khởi chạy tải lại nội dung của nó.

Xem các chỉ số lịch sử

Mục am_low_memory trong nhật ký sự kiện nhị phân cho biết quá trình được lưu trong bộ nhớ đệm cuối cùng đã ngừng hoạt động. Sau đó, hệ thống bắt đầu tắt các dịch vụ.

Xem các chỉ số đập

Các chỉ báo khác về sự cố hệ thống (phân trang, thu hồi trực tiếp, v.v.) bao gồm các chu kỳ tiêu thụ kswapd , kworkermmcqd . (Hãy nhớ rằng báo cáo lỗi được thu thập có thể ảnh hưởng đến các chỉ báo lỗi.)

Nhật ký ANR có thể cung cấp ảnh chụp nhanh bộ nhớ tương tự.

Nhận ảnh chụp nhanh bộ nhớ

Ảnh chụp nhanh bộ nhớ là một trạng thái kết xuất liệt kê các tiến trình gốc và Java đang chạy (để biết chi tiết, hãy tham khảo Xem phân bổ bộ nhớ tổng thể ). Hãy nhớ rằng ảnh chụp nhanh chỉ cung cấp trạng thái tại một thời điểm cụ thể; hệ thống có thể ở trạng thái tốt hơn (hoặc tệ hơn) trước khi chụp ảnh nhanh.

Chương trình phát sóng

Ứng dụng tạo các chương trình phát sóng để gửi các sự kiện trong ứng dụng hiện tại hoặc tới ứng dụng khác. Bộ thu phát sóng đăng ký các tin nhắn cụ thể (thông qua các bộ lọc), cho phép chúng vừa nghe vừa phản hồi một chương trình phát sóng. Báo cáo lỗi chứa thông tin về các chương trình phát sóng đã gửi và các chương trình phát sóng chưa gửi, cũng như một hệ thống kết xuất tất cả các máy thu đang nghe một chương trình phát sóng cụ thể.

Xem các chương trình phát sóng lịch sử

Các chương trình phát sóng lịch sử là những chương trình đã được gửi đi, được liệt kê theo thứ tự thời gian đảo ngược.

Phần tóm tắt là tổng quan về 300 chương trình phát sóng nền trước và 300 chương trình phát sóng nền gần đây nhất.

Phần chi tiết chứa thông tin đầy đủ về 50 chương trình phát sóng nền trước và 50 chương trình phát sóng nền cuối cùng, cũng như các thiết bị thu cho mỗi chương trình phát sóng. Người nhận có:

  • Mục nhập BroadcastFilter được đăng ký trong thời gian chạy và chỉ được gửi đến các tiến trình đang chạy.
  • Mục nhập ResolveInfo được đăng ký thông qua các mục nhập trong bảng kê khai. Trình quản lý hoạt động bắt đầu quy trình cho từng ResolveInfo nếu nó chưa chạy.

Xem các chương trình phát sóng đang hoạt động

Các chương trình phát sóng đang hoạt động là những chương trình chưa được gửi đi. Một số lượng lớn trong hàng đợi có nghĩa là hệ thống không thể gửi các chương trình phát sóng đủ nhanh để theo kịp.

Xem người nghe phát sóng

Để xem danh sách các máy thu đang nghe chương trình phát sóng, hãy kiểm tra Bảng phân giải máy thu trong dumpsys activity broadcasts . Ví dụ sau hiển thị tất cả các máy thu đang lắng nghe USER_PRESENT .

Giám sát sự tranh chấp

Ghi nhật ký tranh chấp màn hình đôi khi có thể cho biết sự tranh chấp màn hình thực tế, nhưng phần lớn thường cho thấy hệ thống đã quá tải nên mọi thứ đã bị chậm lại. Bạn có thể thấy các sự kiện theo dõi dài được ART ghi lại trong nhật ký hệ thống hoặc sự kiện.

Trong nhật ký hệ thống:

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

Trong nhật ký sự kiện:

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]

Biên soạn nền

Việc biên dịch có thể tốn kém và tải thiết bị.

Quá trình biên dịch có thể diễn ra ở chế độ nền khi tải xuống các bản cập nhật của cửa hàng Google Play. Trong trường hợp này, tin nhắn từ ứng dụng cửa hàng Google Play ( finsky ) và installd xuất hiện trước tin nhắn dex2oat .

Quá trình biên dịch cũng có thể diễn ra ở chế độ nền khi ứng dụng đang tải tệp dex chưa được biên dịch. Trong trường hợp này, bạn sẽ không thấy ghi nhật ký finsky hoặc installd .

Chuyện kể

Việc thiết lập tường thuật về một vấn đề (nó bắt đầu như thế nào, điều gì đã xảy ra, hệ thống phản ứng như thế nào) đòi hỏi một dòng thời gian chắc chắn về các sự kiện. Bạn có thể sử dụng thông tin trong báo cáo lỗi để đồng bộ hóa các mốc thời gian trên nhiều nhật ký và xác định dấu thời gian chính xác của báo cáo lỗi.

Đồng bộ hóa dòng thời gian

Một báo cáo lỗi phản ánh nhiều dòng thời gian song song: nhật ký hệ thống, nhật ký sự kiện, nhật ký kernel và nhiều dòng thời gian chuyên biệt cho chương trình phát sóng, số liệu thống kê về pin, v.v. Thật không may, các dòng thời gian thường được báo cáo bằng các cơ sở thời gian khác nhau.

Dấu thời gian của nhật ký hệ thống và sự kiện nằm trong cùng múi giờ với người dùng (cũng như hầu hết các dấu thời gian khác). Ví dụ: khi người dùng nhấn vào nút home, nhật ký hệ thống sẽ báo cáo:

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

Đối với cùng một hành động, nhật ký sự kiện báo cáo:

10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

Nhật ký hạt nhân ( dmesg ) sử dụng cơ sở thời gian khác, gắn thẻ các mục nhật ký theo giây kể từ khi bộ nạp khởi động hoàn tất. Để đăng ký khoảng thời gian này với các khoảng thời gian khác, hãy tìm kiếm thông báo tạm dừng thoáttạm dừng nhập :

<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

Bởi vì nhật ký kernel có thể không bao gồm thời gian trong khi tạm dừng, bạn nên đăng ký nhật ký từng phần giữa các thông báo nhập và thoát tạm dừng. Ngoài ra, nhật ký kernel sử dụng múi giờ UTC và phải được điều chỉnh theo múi giờ của người dùng.

Xác định thời gian báo cáo lỗi

Để xác định thời điểm thực hiện báo cáo lỗi, trước tiên hãy kiểm tra nhật ký hệ thống (Logcat) để biết dumpstate: begin :

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

Tiếp theo, hãy kiểm tra dấu thời gian của nhật ký kernel ( dmesg ) để biết thông báo Starting service 'bugreport' :

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

Hãy thực hiện ngược lại để tìm mối tương quan giữa hai sự kiện, hãy ghi nhớ những lưu ý được đề cập trong Đồng bộ hóa các mốc thời gian . Mặc dù có rất nhiều điều xảy ra sau khi báo cáo lỗi được bắt đầu, nhưng hầu hết hoạt động đều không hữu ích lắm vì hành động báo cáo lỗi sẽ tải hệ thống về cơ bản.

Quyền lực

Nhật ký sự kiện chứa trạng thái nguồn màn hình, trong đó 0 là tắt màn hình, 1 là bật màn hình và 2 là hoàn tất bảo vệ phím.

Báo cáo lỗi cũng chứa số liệu thống kê về khóa chế độ thức, một cơ chế được các nhà phát triển ứng dụng sử dụng để cho biết ứng dụng của họ cần duy trì thiết bị. (Để biết chi tiết về khóa chế độ thức, hãy tham khảo PowerManager.WakeLockGiữ CPU luôn bật .)

Số liệu thống kê về thời lượng khóa chế độ thức tổng hợp chỉ theo dõi thời gian khóa chế độ thức thực sự chịu trách nhiệm giữ cho thiết bị luôn bật và không bao gồm thời gian bật màn hình. Ngoài ra, nếu nhiều khóa chế độ thức được giữ đồng thời thì thời gian duy trì khóa chế độ thức sẽ được phân bổ cho các khóa chế độ thức đó.

Để được trợ giúp thêm về cách trực quan hóa trạng thái nguồn, hãy sử dụng Battery Historian , một công cụ nguồn mở của Google để phân tích mức tiêu thụ pin bằng cách sử dụng tệp báo cáo lỗi của Android.

Gói

Phần DUMP OF SERVICE package chứa các phiên bản ứng dụng (và thông tin hữu ích khác).

Quy trình

Báo cáo lỗi chứa một lượng lớn dữ liệu về các quy trình, bao gồm thời gian bắt đầu và dừng, thời lượng thời gian chạy, các dịch vụ liên quan, điểm oom_adj , v.v. Để biết chi tiết về cách Android quản lý các quy trình, hãy tham khảo Quy trình và Chủ đề .

Xác định thời gian chạy quá trình

Phần procstats chứa số liệu thống kê đầy đủ về thời gian các quy trình và dịch vụ liên quan đã chạy. Để có bản tóm tắt nhanh chóng, dễ đọc, hãy tìm kiếm AGGREGATED OVER để xem dữ liệu trong ba hoặc 24 giờ qua, sau đó tìm kiếm Summary: để xem danh sách các quy trình, thời lượng các quy trình đó đã chạy ở các mức độ ưu tiên khác nhau và RAM của chúng mức sử dụng được định dạng là PSS tối thiểu trung bình/tối thiểu USS trung bình tối đa.

Lý do một quy trình đang chạy

Phần dumpsys activity processes liệt kê tất cả các quy trình hiện đang chạy được sắp xếp theo điểm oom_adj (Android cho biết tầm quan trọng của quy trình bằng cách gán cho quy trình một giá trị oom_adj , giá trị này có thể được cập nhật động bởi Trình quản lý hoạt động). Đầu ra tương tự như kết quả chụp nhanh bộ nhớ nhưng bao gồm thông tin bổ sung về nguyên nhân khiến quá trình chạy. Trong ví dụ bên dưới, các mục in đậm cho biết quy trình gms.persistent đang chạy ở mức ưu tiên vis (hiển thị) vì quy trình hệ thống bị ràng buộc với NetworkLocationService của nó.

Quét

Sử dụng các bước sau để xác định các ứng dụng thực hiện quét Bluetooth Low Energy (BLE) quá mức:

  • Tìm thông điệp tường trình cho BluetoothLeScanner :
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • Xác định vị trí PID trong thông điệp tường trình. Trong ví dụ này, "24840" và "24851" là PID (ID tiến trình) và TID (ID luồng).
  • Xác định vị trí ứng dụng được liên kết với PID:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    

    Trong ví dụ này, tên gói là com.badapp .

  • Tra cứu tên gói trên Google Play để xác định ứng dụng chịu trách nhiệm: https://play.google.com/store/apps/details?id=com.badapp .

Lưu ý : Đối với các thiết bị chạy Android 7.0, hệ thống sẽ thu thập dữ liệu để quét BLE và liên kết các hoạt động này với ứng dụng khởi tạo. Để biết chi tiết, hãy xem Quét năng lượng thấp (LE) và Bluetooth .