Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

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

Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

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 của Android đều hỗ trợ ghi lại các báo cáo lỗi với Android Debug Bridge (adb) ; Phiên bản Android 4.2 trở lên hỗ trợ Tùy chọn dành cho 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 Android chứa dữ liệu logcat dumpstate dumpsys 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 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 và 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ụ cho đầu ra và lệnh grep và / hoặc dumpsys xuất đầu ra.

Logcat

Nhật ký logcat là một 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 đời 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 đại diện chuỗi của thông báo nhật ký đượ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 trong phần này để biết ID quy trình cụ thể (PID) để xem quy trình đang hoạt động như thế nào. Đị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 những điều sau:

  • V: dài dòng
  • D: gỡ lỗi
  • Tô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/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ẽ giết quá trình và chuyển ngăn xếp vào /data/anr . Để phát hiện ra thủ phạm đằng sau 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 ANR in 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 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 máy ảo khớp với ANR bạn đang điều tra, sau đó kiểm tra chuỗi chính của quy trình. Ghi nhớ:

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

Tìm kiếm những bế tắc

Lần đầu tiên bế tắc thường xuất hiện dưới dạng ANR vì các luồng đang bị kẹt. Nếu deadlock tấn công máy chủ hệ thống, cơ quan giám sát cuối cùng sẽ giết 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ực sự.

  • Khi khởi động lại thời gian chạy , máy chủ hệ thống chết 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 , hạt nhân đã bị lỗi; người dùng thấy thiết bị quay trở lại biểu trưng khởi động của Google.

Để tìm các deadlock, hãy kiểm tra các phần dấu vết của VM để tìm một mẫu của sợi A đang đợi thứ gì đó được giữ bởi sợi B, đến lượt nó đang chờ thứ gì đó được giữ bởi sợi 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 việc gì đó chẳng hạn như quay số, chụp ảnh, gửi email, v.v. Từ góc độ báo cáo lỗi, một hoạt động là một việc tập trung duy nhất mà người dùng có thể làm , điều này làm cho việc xác định hoạt động được tập trung trong một vụ tai nạn trở nên rất quan trọng. Các hoạt động (thông qua ActivityManager) chạy các quy trình, do đó, định vị 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ủa 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ử của quá trình bắt đầu, hãy tìm kiếm Start proc .

Thiết bị có đập không?

Để xác định xem thiết bị có đang hoạt động am_proc_died am_proc_start trong một khoảng thời gian ngắn.

Kỉ niệm

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ư một 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 hoạt động vì nó giết 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ề bộ nhớ thấp, hãy kiểm tra nồng độ 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à cản trở các nỗ lực trả 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, nó 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 nhập 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ớ cache cuối cùng đã chết. Sau đó, hệ thống bắt đầu tiêu diệt các dịch vụ.

Xem các chỉ báo đập

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

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

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 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ể trong thời gian; hệ thống có thể có hình dạng tốt hơn (hoặc tệ hơn) trước khi có ảnh chụp nhanh.

Các chương trình phát sóng

Các ứng dụng tạo ra 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 đến một ứng dụng khác. Máy thu phát sóng đăng ký các tin nhắn cụ thể (thông qua bộ lọc), cho phép họ vừa nghe và 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à chương trình phát sóng chưa gửi, cũng như tập hợp tất cả các bộ 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 ngược lại.

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 cuối cùng.

Phần chi tiết chứa thông tin đầy đủ cho 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 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 quy trình đã chạy.
  • Mục nhập ResolveInfo được đăng ký thông qua các mục nhập tệp kê khai. ActivityManager bắt đầu quá 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 chương trình phát sóng

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

Theo dõi sự tranh chấp

Ghi nhật ký tranh chấp màn hình đôi khi có thể chỉ ra sự tranh giành màn hình thực tế, nhưng hầu hết thường cho biết hệ thống đã quá tải nên mọi thứ đã chậm lại. Bạn có thể thấy các sự kiện theo dõi dài được ghi lại bởi ART trong 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 nền

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

Quá trình tổng hợp có thể xảy ra trong nền khi các bản cập nhật 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 tin nhắn dex2oat .

Quá trình biên dịch cũng có thể xảy 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 của một vấn đề (nó bắt đầu như thế nào, điều gì đã xảy ra, hệ thống phản ứng ra sao) đòi hỏi một mốc thời gian chắc chắn của các sự kiện. Bạn có thể sử dụng thông tin trong báo cáo lỗi để đồng bộ 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 tiến trình

Báo cáo lỗi phản ánh nhiều mốc thời gian song song: nhật ký hệ thống, nhật ký sự kiện, nhật ký hạt nhân và nhiều mốc thời gian chuyên biệt cho các 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 mốc thời gian thường được báo cáo bằng cách sử dụng các cơ sở thời gian khác nhau.

Dấu thời gian của hệ thống và nhật ký sự kiện ở 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 trang chủ, 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 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 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 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 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

Bởi vì bản ghi hạt nhân 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 các thông báo tạm ngừng nhập 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 thực hiện một báo cáo lỗi, trước tiên hãy kiểm tra nhật ký hệ thống (Logcat) để biết kết dumpstate: begin :

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

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

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

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

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 đang bật và 2 là khi hoàn tất khóa 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 bật thiết bị. (Để biết chi tiết về khóa chế độ thức, hãy tham khảo PowerManager.WakeLock and Keep CPU on .)

Thống kê 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ữ thiết bị ở chế độ thức 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ời gian khóa chế độ thức được phân bổ trên các khóa chế độ thức đó.

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

Các 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).

Quy trình

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 thời gian bắt đầu và dừ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 quy trình

Phần procstats chứa số liệu thống kê đầy đủ về thời gian các quá trình và dịch vụ liên quan đã chạy. Để có một bản tóm tắt nhanh chóng, con người có thể đọc được, hãy tìm kiếm AGGREGATED OVER để xem dữ liệu từ ba hoặc 24 giờ qua, sau đó tìm kiếm Summary: để xem danh sách các quy trình, thời gian 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 đa / tối thiểu-trung bình-tối đa USS.

Tại sao một tiến 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 mức độ quan trọng của quy trình bằng cách gán giá trị oom_adj cho quy trình, giá trị này có thể được ActivityManager cập nhật động). Đầu ra tương tự như đầu ra của ảnh 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 được in đậm cho biết quy trình gms.persistent đang chạy ở mức ưu tiên hiển thị (hiển thị) vì quy trình hệ thống được liên kết vis 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 báo 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
    
  • Định vị PID trong thông báo nhật ký. Trong ví dụ này, "24840" và "24851" là PID (ID quy trình) và TID (ID luồng).
  • Định vị ứ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 có 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 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 phần quét Năng lượng thấp (LE) và Bluetooth .