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

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

Các báo cáo lỗi Android có chứa dumpsys, dumpstate và Dữ liệu logcat ở định dạng văn bản (.txt), cho phép bạn dễ dàng tìm kiếm cho nội dung cụ thể. Các phần sau đây trình bày chi tiết về các thành phần của báo cáo lỗi, mô tả các vấn đề thường gặp và đưa ra 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 mục đều đưa ra ví dụ cho lệnh và đầu ra grep và/hoặc đầu ra dumpsys.

Logcat

Nhật ký logcat là một tệp kết xuất dựa trên chuỗi của tất cả logcat của bạn. Phần hệ thống dành riêng cho khung và có lịch sử lâu hơn so với thẻ main chứa mọi nội dung 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 nhật ký có định dạng nhị phân. Nó sẽ ít nhiễu 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 mã quy trình cụ thể trong phần này (PID) để xem một quy trình đang làm gì. Định dạng cơ bản là: timestamp PID TID log-level log-tag tag-values.

Nhật ký bao gồm các cấp độ sau:

  • V: chi tiết
  • D: gỡ lỗi
  • I: thông tin
  • W: cảnh báo
  • E: 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/EventLogTag.logTag.

Lỗi ANR và tình trạng tắc nghẽn

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

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

Khi ứng dụng không phản hồi trong một khoảng 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 quy trình và kết xuất ngăn xếp vào /data/anr. Để biết được thủ phạm gây ra lỗi ANR, hãy sử dụng hàm grep cho am_anr trong nhật ký sự kiện nhị phân.

Bạn cũng có thể grep cho ANR in trong nhật ký logcat, chứa thêm thông tin 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 một lỗi ANR. Hãy đảm bảo rằng dấu thời gian và PID trên dấu vết máy ảo khớp với lỗi ANR mà bạn đang điều tra, sau đó hãy kiểm tra luồng chính của quy trình. Lưu ý:

  • Luồng chính chỉ cho bạn biết hoạt động của luồng tại thời điểm xảy ra ANR, có thể tương ứng với hoặc không tương ứng với nguyên nhân thực sự gây ra lỗi ANR. (Ngăn xếp trong báo cáo lỗi có thể không vi phạm; một thiết bị khác có thể đã bị mắc kẹt trong một thời gian dài thời gian (nhưng không đủ lâu để dẫn đến lỗi ANR) trước khi trở nên khó giải quyết.)
  • Nhiều tập hợp dấu vết ngăn xếp (VM TRACES JUST NOWVM TRACES AT LAST ANR). Đảm bảo bạn đang xem chính xác mục.

Tìm điểm tắc nghẽn

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

  • Trong một thời gian chạy khởi động lại, máy chủ hệ thống sẽ ngừng hoạt động và đã khởi động lại; người dùng thấy thiết bị quay lại ảnh động khởi động.
  • Trong quá trình khởi động lại, nhân hệ điều hành đã gặp sự cố; người dùng thấy thiết bị trở lại biểu trưng khởi động của Google.

Để tìm các tắc nghẽn, hãy kiểm tra phần dấu vết máy ảo để tìm mẫu của luồng A đang chờ một nội dung nào đó do luồng B giữ lại, do đó luồng này cũng đang chờ một nội dung nào đó do luồng A giữ.

Hoạt động

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

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

Để xem nhật ký của các hoạt động được tập trung, hãy tìm kiếm am_focused_activity.

Bắt đầu quá trình xem

Để xem nhật ký bắt đầu quy trình, hãy tìm Start proc.

Xác định xem thiết bị có đang bị đơ máy hay không

Để xác định xem thiết bị có đang tình trạng đơ máy, kiểm tra xem hoạt động có tăng bất thường vào khoảng am_proc_died hay không và am_proc_start trong một thời gian ngắn.

Bộ nhớ

Do các thiết bị Android thường bị hạn chế về bộ nhớ thực, 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 vài chỉ báo bộ nhớ thấp cũng như dumpstate cung cấp ảnh chụp nhanh bộ nhớ.

Xác định dung lượng bộ nhớ thấp

Bộ nhớ thấp có thể khiến hệ thống bị sự cố vì nó giết chết một số quy trình để giải phóng 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ề bộ nhớ thấp, kiểm tra nồng độ am_proc_diedam_proc_start mục 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ở nỗ lực quay lại (vì tác vụ mà người dùng đang cố gắng quay lại đã bị vô hiệu hoá). Nếu trình chạy là bị tắt, chương trình 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 chạy tải lại nội dung của nó.

Xem các chỉ báo trong quá khứ

Mục nhập am_low_memory trong nhật ký sự kiện nhị phân cho biết quá trình lưu vào bộ nhớ đệm gần đây nhất đã hết. Sau đó, hệ thống sẽ bắt đầu tắt các dịch vụ.

Xem chỉ báo đơ máy

Các chỉ báo khác về tình trạng đơ máy hệ thống (phân trang, xác nhận lại trực tiếp, v.v.) bao gồm kswapd, kworkermmcqd đang tiêu thụ chu kỳ. (Xin lưu ý rằng việc thu thập báo cáo lỗi có thể ảnh hưởng đến tình trạng đơ máy chỉ báo.)

Nhật ký ANR có thể cung cấp thông tin tổng quan nhanh tương tự về bộ nhớ.

Xem nhanh bộ nhớ

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

Truyền phát

Ứng dụng tạo thông báo truyền tin để gửi các sự kiện trong khoảng thời gian hoặc cho một ứng dụng khác. Các broadcast receiver đăng ký tin nhắn (thông qua bộ lọc), cho phép chúng vừa nghe vừa phản hồi một thông báo truyền tin. Báo cáo lỗi chứa thông tin về tin truyền đã gửi và tin chưa gửi, như là cũng như một dumpsys của tất cả các receiver đang nghe một thông báo truyền tin cụ thể.

Xem chương trình phát sóng trước đây

Thông báo truyền tin trước đây là những tin đã được gửi, được liệt kê trong trình tự thời gian ngược.

Mục tóm tắt là thông tin tổng quan về 300 thông tin mới nhất thông báo truyền tin trên nền trước và 300 thông báo truyền phát trong nền gần đây nhất.

Phần detail chứa đầy đủ thông tin cho 50 thông báo trên nền trước gần đây nhất và 50 thông báo truyền phát trong nền gần đây nhất, cũng như các receiver cho từng thông báo truyền tin. Các bộ thu có:

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

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

Thông báo đang hoạt động là những thông báo chưa được gửi. Một số lượng lớn trong khiến hệ thống không thể gửi thông báo đủ nhanh để theo kịp.

Xem trình nghe truyền phát

Để xem danh sách các receiver đang nghe một thông báo truyền tin, hãy kiểm tra các receiver Bảng trình phân giải trong dumpsys activity broadcasts. Nội dung sau đây Ví dụ sẽ cho thấy tất cả các receiver đang nghe USER_PRESENT.

Theo dõi tranh chấp

Việc ghi nhật ký tranh chấp giám sát đôi khi có thể cho biết tranh chấp giám sát thực tế, nhưng thường biểu thị việc hệ thống quá tải khiến mọi thứ bị chậm lại. Bạn có thể thấy các sự kiện giám sát dài do ART ghi lại trong nhật ký hệ thống hoặc nhật ký 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 dịch ở chế độ 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 trong nền khi các bản cập nhật của Cửa hàng Google Play đang tải xuống. 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 dex2oat tin nhắn.

Quá trình biên dịch cũng có thể diễn ra trong nền khi một ứng dụng đang tải một 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.

Kể chuyện

Xây dựng câu chuyện về một vấn đề (cách vấn đề bắt đầu, điều gì đã xảy ra, cách thức xử lý hệ thống đã phản ứng) đòi hỏi một dòng thời gian sự kiện ổn định. Bạn có thể sử dụng trong báo cáo lỗi để đồng bộ hoá tiến trình 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ộ hoá dòng thời gian

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ý nhân hệ điều hành và nhiều dòng thời gian chuyên biệt cho các tin truyền, số liệu thống kê về pin, v.v. Rất tiếc, dòng thời gian thường được báo cáo theo nhiều cơ sở thời gian.

Dấu thời gian của nhật ký sự kiện và hệ thống phải ở cùng múi giờ với người dùng (như hầu hết là những dấu thời gian khác). Ví dụ: khi người dùng nhấn vào nút trang chủ, báo cáo nhật ký hệ thống:

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 sẽ 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 trong nhật ký vài giây kể từ khi trình tải khởi động hoàn tất. Để đăng ký thang thời gian này với khoảng thời gian, tìm kiếm thông báo thoát tạm ngưngmục nhập tạm ngưng:

<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

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

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

Để xác định thời điểm ghi báo cáo lỗi, trước tiên, hãy kiểm tra nhật ký hệ thống (Logcat) cho 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ý nhân (dmesg) cho thông báo Starting service 'bugreport':

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

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

Nguồn điện

Nhật ký sự kiện chứa trạng thái nguồn của màn hình, trong đó 0 là tắt màn hình, 1 là màn hình bật và 2 là để bật tính năng bảo vệ bàn 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 sử dụng bởi để nhà phát triển ứng dụng cho biết ứng dụng của họ cần có thiết bị hãy tiếp tục bật. (Để biết thông tin chi tiết về khoá chế độ thức, hãy tham khảo PowerManager.WakeLockKeep CPU bật.)

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

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

Gói

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

Quá trình

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

Xác định thời gian chạy của quy trình

Phần procstats có số liệu thống kê đầy đủ về thời lượng các quá trình và dịch vụ được liên kết đang chạy. Để cung cấp thông tin nhanh chóng, dễ đọc cho con người hãy tìm kiếm AGGREGATED OVER để xem dữ liệu từ 3 hoặc 24 giờ qua, sau đó tìm kiếm Summary: để xem danh sách của các quy trình, các quy trình đó đã chạy trong bao lâu với mức độ ưu tiên khác nhau và Mức sử dụng RAM có định dạng PSS tối thiểu/tối đa trung bình-tối đa USS.

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

Phần dumpsys activity processes liệt kê tất cả các quy trình đang chạy được sắp xếp theo điểm oom_adj (Android cho biết rằng tầm quan trọng của xử lý bằng cách chỉ định giá trị oom_adj cho quy trình ActivityManager có thể tự động cập nhật). Kết quả tương tự như của ảnh chụp nhanh bộ nhớ nhưng bao gồm thông tin bổ sung thông tin về nguyên nhân khiến quá trình này 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 được liên kết với NetworkLocationService.

Bản quét

Hãy làm theo các bước sau đây để xác định những ứng dụng hoạt động quá mức Quét Bluetooth năng lượng thấp (BLE):

  • Tìm thông điệp nhật ký 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 nhật ký. Trong ví dụ này là "24840" và "24851" là PID (mã nhận dạng quy trình) và TID (mã nhận dạng luồng).
  • Xác định vị trí ứng dụng 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 có trách nhiệm ứng dụng: 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 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 thông tin chi tiết, hãy xem Năng lượng thấp (LE) và quét Bluetooth.