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

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

Báo cáo lỗi 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 vấn đề thường gặp, đồng thời đưa ra các mẹo hữu ích và 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à một tệp kết xuất dựa trên chuỗi của tất cả thông tin logcat. Phần system (hệ thống) được dành riêng cho khung và có nhật ký dài hơn phần main (chính) chứa mọi phần 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ũ.

Xem nhật ký sự kiện

Nhật ký này chứa các chuỗi đại diện cho thông điệp nhật ký có định dạng nhị phân. Nhật ký này í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 kiếm mã nhận dạng quy trình (PID) cụ thể trong phần này để xem quy trình đang làm 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: chi tiết
  • D: gỡ lỗi
  • I: thông tin
  • W: cảnh báo
  • E: lỗi

 

Đối với 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.

Lỗi ANR và 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 lỗi Ứng dụng không phản hồi (ANR) và sự kiện tắc nghẽn.

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

Khi một ứ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ẽ chấm dứt quy trình và kết xuất ngăn xếp vào /data/anr. Để tìm ra nguyên nhân gây ra lỗi ANR, hãy tìm am_anr trong nhật ký sự kiện nhị phân.

Bạn cũng có thể tìm kiếm ANR in trong nhật ký logcat. Nhật ký này 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 lỗi 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 lỗi ANR. Đả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 đó kiểm tra luồng chính của quy trình. Lưu ý:

  • Luồng chính chỉ cho bạn biết luồng đang làm gì tại thời điểm xảy ra lỗi ANR. Luồng này có thể tương ứng 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 có lỗi; có thể một lỗi khác đã bị treo trong một thời gian dài – nhưng chưa đủ lâu để gây ra lỗi ANR – trước khi được khắc phục.)
  • Có thể tồn tại nhiều bộ dấu vết ngăn xếp (VM TRACES JUST NOWVM TRACES AT LAST ANR). Đảm bảo bạn đang xem đúng phần.

Tìm tình trạng tắc nghẽn

Tình trạng tắc nghẽn thường xuất hiện dưới dạng lỗi ANR vì các luồng bị treo. Nếu tình trạng tắc nghẽn xảy ra với máy chủ hệ thống, thì trình giám sát cuối cùng sẽ loại bỏ tình trạng này, 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à một quá trình khởi động lại thời gian chạy thay vì khởi động lại thực sự.

  • Trong quá trình khởi động lại thời gian chạy, máy chủ hệ thống sẽ ngừng hoạt động và khởi động lại; người dùng sẽ 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 sẽ thấy thiết bị quay lại biểu trưng khởi động của Google.

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

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 việc nào đó, chẳng hạn 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ể làm, điều này khiến việc xác định vị trí hoạt động đang được lấy làm tâm điểm trong sự cố trở nên rất quan trọng. Các hoạt động (thông qua ActivityManager) chạy các quy trình, vì vậy, việc xác định tất cả các điểm dừng và bắt đầu 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 được lấy làm tâm điểm

Để xem nhật ký hoạt động được lấy tiêu điểm, hãy tìm am_focused_activity.

Bắt đầu quy 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ó bị tình trạng đơ hay không

Để xác định xem thiết bị có đang đổ rác 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.

Bộ nhớ

Vì các thiết bị Android thường có bộ nhớ vật lý bị 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 bản tổng quan nhanh về bộ nhớ.

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

Bộ nhớ thấp có thể khiến hệ thống bị treo vì hệ thống sẽ đóng một số quy trình để giải phóng bộ nhớ nhưng vẫn tiếp tục khởi động các quy trình khác. Để xem bằng chứng xác thực về việc bộ nhớ sắp hết, hãy kiểm tra mức độ tập trung của các mục nhập 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à ngăn chặn 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ị tắt). Nếu trình chạy bị tắt, trình chạy sẽ khởi động lại khi người dùng chạm vào nút màn hình chính và nhật ký cho thấy trình chạy sẽ tải lại nội dung của trình chạy.

Xem chỉ báo trong quá khứ

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

Xem chỉ báo hoạt động ngẫu nhiên

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

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

Lấy ả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 quy trình Java và gốc đang chạy (để biết thông tin chi tiết, hãy tham khảo phần Xem mức phân bổ bộ nhớ tổng thể). Xin lưu ý 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 nhanh.

Truyền phát

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

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

Thông báo truyền tin trong quá khứ là những thông báo đã được gửi, được liệt kê theo thứ tự thời gian đảo ngược.

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

Phần chi tiết chứa thông tin đầy đủ về 50 thông báo truyền tin trên nền trước và 50 thông báo truyền tin trên nền gần đây nhất, cũng như các trình thu nhận cho mỗi thông báo truyền tin. Thiết bị 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 quy trình đang chạy.
  • Mục ResolveInfo được đăng ký thông qua các mục trong tệp kê khai. ActivityManager sẽ bắt đầu quy trình cho mỗi ResolveInfo nếu quy trình này chưa chạy.

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

Thông báo truyền tin đang hoạt động là những thông báo chưa được gửi. Một số lượng lớn trong hàng đợi có nghĩa là hệ thống không thể điều phối các thông báo truyền tin đủ nhanh để bắt kịp.

Xem trình nghe thông báo truyền tin

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

Theo dõi tranh chấp

Việc ghi nhật ký tranh chấp màn hình đôi khi có thể cho biết tình trạng tranh chấp màn hình thực tế, nhưng thường cho biết hệ thống quá tải nên mọi thứ đều 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 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

Quá trình 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 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, thông báo từ ứng dụng Cửa hàng Google Play (finsky) và installd sẽ xuất hiện trước thông báo dex2oat.

Quá trình biên dịch cũng có thể diễn ra ở chế độ 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 hoạt động ghi nhật ký finsky hoặc installd.

Kể chuyện

Việc thiết lập câu chuyện về một vấn đề (cách bắt đầu, điều gì đã xảy ra, cách hệ thống phản ứng) đòi hỏi một tiến trình sự kiện rõ ràng. Bạn có thể sử dụng thông tin 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.

Tiến trình đồng bộ hoá

Báo cáo lỗi phản ánh nhiều tiến trình song song: nhật ký hệ thống, nhật ký sự kiện, nhật ký hạt nhân và nhiều tiến trình chuyên biệt cho thông báo truyền tin, số liệu thống kê pin, v.v. Rất tiếc, các tiến trình 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à nhật ký 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 màn hình chính, 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 một cơ sở thời gian khác, gắn thẻ các mục nhật ký bằng giây kể từ khi trình tải khởi động hoàn tất. Để đăng ký tiến trình này cho các tiến trình khác, hãy tìm thông báo tạm ngưng thoáttạm ngư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

Vì nhật ký hạt nhân có thể không bao gồm thời gian trong khi tạm ngưng, nên bạn nên đăng ký nhật ký theo từng phần giữa thông báo tạm ngưng và thoát. Ngoài ra, nhật ký hạt nhân 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 lấy 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ý hạt nhân (dmesg) cho thông báo Starting service 'bugreport':

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

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

Sức mạnh

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

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

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

Để được trợ giúp thêm về việc trực quan hoá 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 người dùng pin bằng các tệp báo cáo lỗi Android.

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

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 chạy, các dịch vụ liên quan, đ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 phần Quy trình và luồng.

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

Mục procstats chứa số liệu thống kê đầy đủ về thời gian chạy của các quy trình và dịch vụ liên quan. Để xem nhanh bản tóm tắt mà con người có thể đọc được, hãy tìm AGGREGATED OVER để xem dữ liệu trong 3 hoặc 24 giờ qua, sau đó tìm Summary: để xem danh sách các quy trình, thời gian các quy trình đó chạy ở nhiều mức độ ưu tiên và mức sử dụng RAM được định dạng là PSS tối thiểu-trung bình-tối đa/USS tối thiểu-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 đang chạy được sắp xếp theo điểm số 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 ActivityManager cập nhật linh động). Kết quả tương tự như kết quả của ảnh chụp nhanh bộ nhớ nhưng bao gồm thêm thông tin về nguyên nhân khiến quá trình này chạy. Trong ví dụ dưới đây, 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 để xác định những ứng dụng thực hiện quá nhiều thao tá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
    
  • Tìm PID trong thông điệp nhật ký. Trong ví dụ này, "24840" và "24851" là PID (mã nhận dạng quy trình) và TID (mã nhận dạng luồng).
  • Tìm ứ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.

  • Hãy 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 cho hoạt động 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 phần Bluetooth năng lượng thấp (LE) và quét Bluetooth.