Trang này cung cấp trợ giúp khắc phục sự cố và câu trả lời cho các câu hỏi thường gặp về cách sử dụng Crashlytics. Nếu bạn không thể tìm thấy những gì bạn đang tìm kiếm hoặc cần trợ giúp thêm, hãy liên hệ với bộ phận hỗ trợ của Firebase .
Khắc phục sự cố chung/Hỏi đáp
Nếu bạn không thấy người dùng không gặp sự cố, nhật ký breadcrumb và/hoặc cảnh báo tốc độ, chúng tôi khuyên bạn nên kiểm tra cấu hình ứng dụng của mình cho Google Analytics.
Đảm bảo rằng bạn đã bật Google Analytics trong dự án Firebase của mình.
Đảm bảo rằng Chia sẻ dữ liệu được bật cho Google Analytics trong trang Tích hợp > Google Analytics của bảng điều khiển Firebase. Lưu ý rằng Cài đặt chia sẻ dữ liệu được hiển thị trong bảng điều khiển Firebase nhưng được quản lý trong bảng điều khiển Google Analytics.
Ngoài SDK Crashlytics Firebase, hãy đảm bảo rằng bạn đã thêm SDK Firebase dành cho Google Analytics vào ứng dụng của mình ( iOS+ | Android ).
Đảm bảo rằng bạn đang sử dụng phiên bản mới nhất cho tất cả SDK Firebase của mình ( iOS+ | Android ).
Đặc biệt kiểm tra xem bạn có đang sử dụng tối thiểu các phiên bản sau của SDK Firebase cho Google Analytics không: iOS+ — v6.3.1+ (v8.9.0+ cho macOS và tvOS) | Android — v17.2.3+(BoM v24.7.1+) .
Bạn có thể nhận thấy hai định dạng khác nhau cho các sự cố được liệt kê trong bảng Sự cố của bạn trong bảng điều khiển Firebase. Đây là lý do tại sao!
Crashlytics phân tích tất cả các sự kiện từ ứng dụng của bạn — sự cố, sự cố không nghiêm trọng và ANR — đồng thời nhóm các sự kiện tương tự thành các vấn đề riêng biệt. Vào tháng 1 năm 2023, chúng tôi đã ra mắt một công cụ phân tích cải tiến để nhóm các sự kiện dựa trên mã ứng dụng của bạn và một thiết kế cập nhật để hiển thị các vấn đề mới.
Đây là những gì bạn sẽ trải nghiệm với những cải tiến này:
Siêu dữ liệu được sửa đổi hiển thị trong hàng vấn đề
Giờ đây, việc hiểu và xử lý sự cố trong ứng dụng của bạn trở nên dễ dàng hơn.Ít vấn đề trùng lặp hơn
Thay đổi số dòng không dẫn đến một vấn đề mới.Cảnh báo và tín hiệu có ý nghĩa hơn
Một vấn đề mới thực sự đại diện cho một lỗi mới.Tìm kiếm mạnh mẽ hơn
Mỗi vấn đề chứa nhiều siêu dữ liệu có thể tìm kiếm hơn, như loại ngoại lệ và tên gói.
Đây là cách những cải tiến này được triển khai:
Khi nhận được các sự kiện mới từ ứng dụng của bạn, chúng tôi sẽ kiểm tra xem các sự kiện đó có khớp với sự cố hiện có hay không.
Nếu không có kết quả phù hợp, chúng tôi sẽ tự động áp dụng thuật toán nhóm sự kiện thông minh hơn cho sự kiện đó và tạo sự cố mới với thiết kế siêu dữ liệu được cải tiến.
Đây là bản cập nhật lớn đầu tiên mà chúng tôi thực hiện cho nhóm sự kiện của mình. Nếu bạn có phản hồi hoặc gặp phải bất kỳ vấn đề nào, vui lòng cho chúng tôi biết bằng cách gửi báo cáo.
Crashlytics hỗ trợ báo cáo ANR cho các ứng dụng Android từ các thiết bị chạy Android 11 trở lên. API cơ bản mà chúng tôi sử dụng để thu thập ANR ( getHistoricalProcessExitReasons ) đáng tin cậy hơn SIGQUIT hoặc các phương pháp tiếp cận dựa trên cơ quan giám sát. API này chỉ khả dụng trên các thiết bị Android 11 trở lên.
Có thể có sự không khớp giữa số lượng ANR giữa Google Play và Crashlytics. Điều này được mong đợi là do sự khác biệt trong cơ chế thu thập và báo cáo dữ liệu ANR. Crashlytics báo cáo ANR khi ứng dụng khởi động lần tiếp theo, trong khi Android Vitals gửi dữ liệu ANR sau khi ANR xảy ra.
Ngoài ra, Crashlytics chỉ hiển thị ANR xảy ra trên các thiết bị chạy Android 11 trở lên, so với Google Play hiển thị ANR từ các thiết bị có dịch vụ Google Play và chấp nhận đồng ý thu thập dữ liệu.
Chuỗi công cụ LLVM và GNU có các giá trị mặc định và cách xử lý riêng biệt cho phân đoạn chỉ đọc của các tệp nhị phân trong ứng dụng của bạn, điều này có thể tạo ra các dấu vết ngăn xếp không nhất quán trong bảng điều khiển Firebase. Để giảm thiểu điều này, hãy thêm các cờ liên kết sau vào quy trình xây dựng của bạn:
Nếu bạn đang sử dụng trình liên kết
lldtừ chuỗi công cụ LLVM, hãy thêm:-Wl,--no-rosegmentNếu bạn đang sử dụng trình liên kết
ld.goldtừ chuỗi công cụ GNU, hãy thêm:-Wl,--rosegment
Nếu bạn vẫn thấy dấu vết ngăn xếp không nhất quán (hoặc nếu không có cờ nào phù hợp với chuỗi công cụ của bạn), thay vào đó, hãy thử thêm phần sau vào quy trình xây dựng của bạn:
-fno-omit-frame-pointer
Plugin Crashlytics bao gồm một trình tạo tệp biểu tượng Breakpad tùy chỉnh . Nếu bạn thích sử dụng tệp nhị phân của riêng mình để tạo các tệp ký hiệu Breakpad (ví dụ: nếu bạn muốn tạo tất cả các tệp thực thi gốc trong chuỗi xây dựng của mình từ nguồn), hãy sử dụng thuộc tính tiện ích mở rộng symbolGeneratorBinary tùy chọn để chỉ định đường dẫn đến tệp thực thi.
Bạn có thể chỉ định đường dẫn đến tệp nhị phân trình tạo tệp ký hiệu Breakpad theo một trong hai cách sau:
Tùy chọn 1 : Chỉ định đường dẫn thông qua tiện ích mở rộng
firebaseCrashlyticstrong tệpbuild.gradlecủa bạnThêm phần sau vào tệp
build.gradlecấp ứng dụng của bạn:android { // ... buildTypes { // ... release { // ... firebaseCrashlytics { // existing; required for either symbol file generator nativeSymbolUploadEnabled true // Add this optional new block to specify the path to the executable symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }Tùy chọn 2 : Chỉ định đường dẫn qua một dòng thuộc tính trong tệp thuộc tính Gradle của bạn
Bạn có thể sử dụng thuộc tính
com.google.firebase.crashlytics.symbolGeneratorBinaryđể chỉ định đường dẫn đến tệp thực thi.Bạn có thể cập nhật tệp thuộc tính Gradle theo cách thủ công hoặc cập nhật tệp qua dòng lệnh. Ví dụ: để chỉ định đường dẫn qua dòng lệnh, hãy sử dụng lệnh như sau:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
Nếu bạn thấy ngoại lệ sau, có thể bạn đang sử dụng phiên bản DexGuard không tương thích với SDK Crashlytics Firebase:
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
Ngoại lệ này không làm hỏng ứng dụng của bạn nhưng ngăn ứng dụng gửi báo cáo sự cố. Để khắc phục điều này:
Đảm bảo bạn đang sử dụng bản phát hành DexGuard 8.x mới nhất. Phiên bản mới nhất chứa các quy tắc mà SDK Firebase Crashlytics yêu cầu.
Nếu bạn không muốn thay đổi phiên bản DexGuard của mình, hãy thử thêm dòng sau vào quy tắc che giấu (trong tệp cấu hình DexGuard của bạn):
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
Khi một ứng dụng sử dụng trình mã hóa mã hóa không hiển thị phần mở rộng tệp, Crashlytics sẽ tạo từng vấn đề với phần mở rộng tệp .java theo mặc định.
Để Crashlytics có thể tạo ra sự cố với phần mở rộng tệp chính xác, hãy đảm bảo ứng dụng của bạn sử dụng thiết lập sau:
- Sử dụng Android Gradle 4.2.0 trở lên
- Sử dụng R8 với obfuscation được bật. Để cập nhật ứng dụng của bạn lên R8, hãy làm theo tài liệu này .
Lưu ý rằng sau khi cập nhật lên thiết lập được mô tả ở trên, bạn có thể bắt đầu thấy các sự cố .kt mới trùng lặp với các sự cố .java hiện có. Xem Câu hỏi thường gặp để tìm hiểu thêm về trường hợp đó.
Bắt đầu từ giữa tháng 12 năm 2021, Crashlytics đã cải thiện khả năng hỗ trợ cho các ứng dụng sử dụng Kotlin.
Cho đến gần đây, các trình mã hóa có sẵn không hiển thị phần mở rộng tệp, vì vậy Crashlytics đã tạo từng sự cố với phần mở rộng tệp .java theo mặc định. Tuy nhiên, kể từ Android Gradle 4.2.0, R8 hỗ trợ các phần mở rộng tệp.
Với bản cập nhật này, Crashlytics hiện có thể xác định xem mỗi lớp được sử dụng trong ứng dụng có được viết bằng Kotlin hay không và bao gồm tên tệp chính xác trong chữ ký vấn đề. Sự cố hiện được quy chính xác cho tệp .kt (nếu thích hợp) nếu ứng dụng của bạn có thiết lập sau:
- Ứng dụng của bạn sử dụng Android Gradle 4.2.0 trở lên.
- Ứng dụng của bạn sử dụng R8 đã bật che giấu.
Vì các sự cố mới hiện bao gồm phần mở rộng tệp chính xác trong chữ ký sự cố của chúng, nên bạn có thể thấy các sự cố .kt mới thực ra chỉ là bản sao của các sự cố có nhãn .java hiện có. Trong bảng điều khiển Firebase, chúng tôi cố gắng xác định và liên lạc với bạn nếu sự cố .kt mới có thể là bản sao của sự cố có nhãn .java hiện có.
Giá trị không gặp sự cố thể hiện tỷ lệ phần trăm người dùng tương tác với ứng dụng của bạn nhưng không gặp sự cố trong một khoảng thời gian cụ thể.
Đây là công thức tính phần trăm người dùng không gặp sự cố. Giá trị đầu vào của nó được cung cấp bởi Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
Khi sự cố xảy ra, Google Analytics sẽ gửi loại sự kiện
app_exceptionvà CRASHED_USERS biểu thị số lượng người dùng được liên kết với loại sự kiện đó.ALL_USERS đại diện cho tổng số người dùng đã tương tác với ứng dụng của bạn trong khoảng thời gian mà bạn đã chọn từ menu thả xuống ở phía trên bên phải của bảng điều khiển Crashlytics.
Tỷ lệ phần trăm người dùng không gặp sự cố là tổng hợp theo thời gian , không phải mức trung bình.
Ví dụ: hãy tưởng tượng ứng dụng của bạn có ba người dùng; chúng tôi sẽ gọi họ là Người dùng A, Người dùng B và Người dùng C. Bảng sau đây cho biết những người dùng nào đã tương tác với ứng dụng của bạn mỗi ngày và những người dùng nào đã gặp sự cố vào ngày hôm đó:
| Thứ hai | Thứ ba | Thứ Tư | |
|---|---|---|---|
| Người dùng đã tương tác với ứng dụng của bạn | A, B, C | A, B, C | A, B |
| Người dùng gặp sự cố | C | b | MỘT |
Vào Thứ Tư, tỷ lệ người dùng không gặp sự cố của bạn là 50% (cứ 2 người dùng thì có 1 người không gặp sự cố).
Hai trong số những người dùng của bạn đã tương tác với ứng dụng của bạn vào Thứ Tư, nhưng chỉ một trong số họ (Người dùng B) không gặp sự cố.Trong 2 ngày qua, tỷ lệ người dùng không gặp sự cố của bạn là 33,3% (cứ 3 người dùng thì có 1 người không gặp sự cố).
Ba trong số những người dùng của bạn đã tương tác với ứng dụng của bạn trong hai ngày qua, nhưng chỉ một trong số họ (Người dùng C) không gặp sự cố.Trong 3 ngày qua, tỷ lệ người dùng không gặp sự cố của bạn là 0% (0 trong số 3 người dùng không gặp sự cố).
Ba trong số những người dùng của bạn đã tương tác với ứng dụng của bạn trong ba ngày qua, nhưng không có người nào trong số họ không gặp sự cố.
Ghi chú cho phép các thành viên dự án bình luận về các vấn đề cụ thể bằng các câu hỏi, cập nhật trạng thái, v.v.
Khi một thành viên dự án đăng ghi chú, ghi chú đó sẽ được gắn nhãn bằng email của tài khoản Google của họ. Địa chỉ email này được hiển thị cùng với ghi chú cho tất cả các thành viên dự án có quyền truy cập để xem ghi chú.
Phần sau đây mô tả quyền truy cập cần thiết để xem, viết và xóa ghi chú:
Các thành viên dự án với bất kỳ vai trò nào sau đây có thể xem và xóa ghi chú hiện có cũng như viết ghi chú mới về một vấn đề.
Các thành viên dự án có bất kỳ vai trò nào sau đây có thể xem các ghi chú được đăng trên một vấn đề, nhưng họ không thể xóa hoặc viết ghi chú.
- Trình xem dự án , Trình xem Firebase , Trình xem chất lượng hoặc Trình xem Crashlytics
tích hợp
Nếu dự án của bạn sử dụng Crashlytics cùng với SDK quảng cáo trên thiết bị di động của Google, thì có khả năng trình báo cáo sự cố đang can thiệp khi đăng ký trình xử lý ngoại lệ. Để khắc phục sự cố, hãy tắt báo cáo sự cố trong SDK quảng cáo trên thiết bị di động bằng cách gọi disableSDKCrashReporting .
Sau khi bạn liên kết Crashlytics với BigQuery, các bộ dữ liệu mới mà bạn tạo sẽ tự động được đặt ở Hoa Kỳ, bất kể vị trí của dự án Firebase của bạn.
hỗ trợ nền tảng
Firebase Crashlytics NDK không hỗ trợ ARMv5 (armeabi). Hỗ trợ cho ABI này đã bị xóa kể từ NDK r17.
Các vấn đề hồi quy
Sự cố đã xảy ra hồi quy khi bạn đã đóng sự cố trước đó nhưng Crashlytics nhận được báo cáo mới cho biết sự cố đã xảy ra lại. Crashlytics tự động mở lại các sự cố đã được giải quyết này để bạn có thể giải quyết chúng sao cho phù hợp với ứng dụng của mình.
Dưới đây là một tình huống ví dụ giải thích cách Crashlytics phân loại sự cố là hồi quy:
- Lần đầu tiên, Crashlytics nhận được báo cáo sự cố về Sự cố "A". Crashlytics mở một vấn đề tương ứng cho sự cố đó (Vấn đề "A").
- Bạn nhanh chóng khắc phục lỗi này, đóng Sự cố "A" rồi phát hành phiên bản mới của ứng dụng.
- Crashlytics nhận được một báo cáo khác về Sự cố "A" sau khi bạn đã đóng sự cố.
- Nếu báo cáo là từ một phiên bản ứng dụng mà Crashlytics đã biết khi bạn đóng vấn đề (có nghĩa là phiên bản đó đã gửi báo cáo sự cố cho bất kỳ sự cố nào), thì Crashlytics sẽ không coi sự cố là đã được xử lý lại. Vấn đề sẽ vẫn đóng cửa.
- Nếu báo cáo đến từ một phiên bản ứng dụng mà Crashlytics không biết khi bạn đóng sự cố (có nghĩa là phiên bản đó chưa bao giờ gửi bất kỳ báo cáo sự cố nào cho bất kỳ sự cố nào), thì Crashlytics coi sự cố đã được giải quyết và sẽ mở lại sự cố .
Khi sự cố được giải quyết, chúng tôi sẽ gửi cảnh báo phát hiện sự cố và thêm tín hiệu hồi quy vào sự cố để cho bạn biết rằng Crashlytics đã mở lại sự cố. Nếu bạn không muốn một sự cố mở lại do thuật toán hồi quy của chúng tôi, hãy "tắt" sự cố thay vì đóng nó.
Nếu một báo cáo đến từ một phiên bản ứng dụng cũ chưa bao giờ gửi bất kỳ báo cáo sự cố nào khi bạn đóng sự cố, thì Crashlytics coi sự cố đã được khắc phục và sẽ mở lại sự cố.
Tình huống này có thể xảy ra trong trường hợp sau: Bạn đã sửa lỗi và phát hành phiên bản mới của ứng dụng, nhưng bạn vẫn có người dùng trên các phiên bản cũ hơn mà không sửa lỗi. Nếu tình cờ, một trong những phiên bản cũ hơn đó chưa bao giờ gửi bất kỳ báo cáo sự cố nào khi bạn đóng sự cố và những người dùng đó bắt đầu gặp lỗi, thì những báo cáo sự cố đó sẽ gây ra sự cố đã được giải quyết.
Nếu bạn không muốn một sự cố mở lại do thuật toán hồi quy của chúng tôi, hãy "tắt" sự cố thay vì đóng nó.