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ề việc sử dụng Crashlytics. Nếu bạn không thể tìm thấy những gì mình đ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/Câu hỏi thường gặp
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ố trong bảng điều khiển Firebase. Và bạn cũng có thể nhận thấy một tính năng được gọi là "biến thể" trong một số vấn đề của mình. Đây là lý do tại sao!
Vào đầu năm 2023, chúng tôi đã triển khai một công cụ phân tích cải tiến để nhóm các sự kiện cũng như thiết kế cập nhật và một số tính năng nâng cao dành cho các vấn đề mới (như biến thể!). Hãy xem bài đăng blog gần đây của chúng tôi để biết tất cả thông tin chi tiết, nhưng bạn có thể đọc phần bên dưới để biết những điểm nổi bật.
Crashlytics phân tích tất cả các sự kiện từ ứng dụng của bạn (như sự cố, sự cố không gây tử vong và ANR) và tạo các nhóm sự kiện được gọi là sự cố — tất cả các sự kiện trong một sự cố đều có một điểm lỗi chung.
Để nhóm các sự kiện thành những vấn đề này, công cụ phân tích cải tiến hiện xem xét nhiều khía cạnh của sự kiện, bao gồm các khung trong dấu vết ngăn xếp, thông báo ngoại lệ, mã lỗi và các đặc điểm nền tảng hoặc loại lỗi khác.
Tuy nhiên, trong nhóm sự kiện này, dấu vết ngăn xếp dẫn đến lỗi có thể khác nhau. Dấu vết ngăn xếp khác có thể có nghĩa là nguyên nhân cốt lõi khác. Để thể hiện sự khác biệt có thể có này trong một vấn đề, giờ đây chúng tôi tạo các biến thể trong các vấn đề - mỗi biến thể là một nhóm nhỏ các sự kiện trong một vấn đề có cùng điểm lỗi và dấu vết ngăn xếp tương tự. Với các biến thể, bạn có thể gỡ lỗi các dấu vết ngăn xếp phổ biến nhất trong một sự cố và xác định xem các nguyên nhân cốt lõi khác nhau có dẫn đến lỗi hay không.
Đâ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 tân trang lại được hiển thị trong hàng vấn đề
Giờ đây, việc hiểu và phân loại các vấn đề 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
Việc thay đổi số dòng không dẫn đến một vấn đề mới.Dễ dàng gỡ lỗi các vấn đề phức tạp hơn với nhiều nguyên nhân gốc rễ khác nhau
Sử dụng các biến thể để gỡ lỗi các dấu vết ngăn xếp phổ biến nhất trong một sự cố.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 dễ 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 sự kiện mới từ ứng dụng của bạn, chúng tôi sẽ kiểm tra xem chúng có khớp với vấn đề hiện tại hay không.
Nếu không có kết quả trùng khớ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 ra vấn đề 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 đối với nhóm sự kiện của mình. Nếu bạn có phản hồi hoặc gặp 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.
Nếu bạn không nhìn thấy các số liệu không gặp sự cố (chẳng hạn như phiên và số người dùng không gặp sự cố) và/hoặc cảnh báo tốc độ, hãy đảm bảo rằng bạn đang sử dụngCrashlytics SDK v18.6.0+ (hoặc Firebase BoM v32.6.0+).
Nếu bạn không thấy nhật ký đường dẫn , chúng tôi khuyên bạn nên kiểm tra cấu hình ứng dụng của mình để tìm Google Analytics. Đảm bảo bạn đáp ứng các yêu cầu sau:
Bạn đã bật Google Analytics trong dự án Firebase của mình.
Bạn đã bật Chia sẻ dữ liệu cho Google Analytics. Tìm hiểu thêm về cài đặt này trong Quản lý cài đặt chia sẻ dữ liệu Analytics của bạn
Bạn đãđã thêm SDK Firebase cho Google Analyticsvào ứng dụng của bạn. SDK này phải được thêm vào ngoài SDK Crashlytics.
Bạn đang sử dụngphiên bản SDK Firebase mới nhất l10ncho tất cả các sản phẩm bạn sử dụng trong ứng dụng của mình.
Đặc biệt hãy kiểm tra xem bạn có đang sử dụng phiên bản tối thiểu sau của SDK Firebase cho Google Analytics hay không:
Android — v17.2.3+ (BoM v24.7.1+) .
Crashlytics hỗ trợ báo cáo ANR cho ứ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 so với các phương pháp tiếp cận dựa trên SIGQUIT hoặc cơ quan giám sát. API này chỉ khả dụng trên các thiết bị Android 11+.
Nếu một số ANR của bạn thiếu BuildId
s, hãy khắc phục sự cố như sau:
Đảm bảo rằng bạn đang sử dụng phiên bản plugin Crashlytics Android SDK và Crashlytics Gradle cập nhật.
Nếu bạn thiếu
BuildId
cho Android 11 và một số ANR của Android 12 thì có thể bạn đang sử dụng SDK, plugin Gradle hoặc cả hai đã lỗi thời. Để thu thập đúng cáchBuildId
cho các ANR này, bạn cần sử dụng các phiên bản sau:- Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
- Plugin Crashlytics cho Gradle v2.9.4+
Kiểm tra xem bạn có đang sử dụng vị trí không chuẩn cho thư viện dùng chung của mình hay không.
Nếu bạn chỉ thiếu
BuildId
cho thư viện dùng chung của ứng dụng thì có thể bạn hiện không sử dụng vị trí mặc định, tiêu chuẩn cho thư viện dùng chung. Nếu đúng như vậy thì Crashlytics có thể không xác định đượcBuildId
được liên kết. Chúng tôi khuyên bạn nên cân nhắc sử dụng vị trí tiêu chuẩn cho thư viện dùng chung.Đảm bảo rằng bạn không loại bỏ
BuildId
trong quá trình xây dựng.Lưu ý rằng các mẹo khắc phục sự cố sau đây áp dụng cho cả ANR và sự cố gốc.
Kiểm tra xem
BuildId
có tồn tại hay không bằng cách chạyreadelf -n
trên tệp nhị phân của bạn. Nếu không cóBuildId
s, hãy thêm-Wl,--build-id
vào các cờ cho hệ thống xây dựng của bạn.Kiểm tra xem bạn có vô tình loại bỏ
BuildId
trong nỗ lực giảm kích thước APK của mình hay không.Nếu bạn giữ lại các phiên bản đã được gỡ bỏ và chưa được gỡ bỏ của một thư viện, hãy đảm bảo trỏ đến phiên bản chính xác trong mã của bạ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 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+, 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 trong các tệp nhị phân của ứng dụng, đ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 quá trình xây dựng của bạn:
Nếu bạn đang sử dụng trình liên kết
lld
từ chuỗi công cụ LLVM, hãy thêm:-Wl,--no-rosegment
Nếu bạn đang sử dụng trình liên kết
ld.gold
từ chuỗi công cụ GNU, hãy thêm:-Wl,--rosegment
Nếu bạn vẫn thấy sự không nhất quán trong dấu vết ngăn xếp (hoặc nếu cả hai cờ đều không 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 gói một trình tạo tệp biểu tượng Breakpad tùy chỉnh . Nếu bạn muốn sử dụng tệp nhị phân của riêng mình để tạo tệp ký hiệu Breakpad (ví dụ: nếu bạn muốn xây dựng 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 của trình tạo tệp ký hiệu Breakpad theo một trong hai cách:
Tùy chọn 1 : Chỉ định đường dẫn qua tiện ích mở rộng
firebaseCrashlytics
trong tệpbuild.gradle
của bạnThêm phần sau vào tệp
build.gradle
cấ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 thủ công tệp thuộc tính Gradle của mình 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 thì có thể bạn đang sử dụng phiên bản DexGuard không tương thích với SDK Firebase Crashlytics:
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 được 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 làm rối mã nguồn của bạn (trong tệp cấu hình DexGuard):
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
Khi một ứng dụng sử dụng trình obfuscator không hiển thị phần mở rộng tệp, Crashlytics sẽ tạo ra 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 khi bật tính năng xáo trộn. Để 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 vấn đề .kt
mới trùng lặp với các vấn đề .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 làm xáo trộn có sẵn đã không hiển thị phần mở rộng tệp, do đó, Crashlytics đã tạo ra từng vấn đề 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ợ 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à đưa tên tệp chính xác vào chữ ký phát hành. Hiện tại, các sự cố được phân bổ 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 và đã bật chức năng làm rối mã nguồn.
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ý vấn đề của chúng nên bạn có thể thấy các vấn đề .kt
mới thực ra chỉ là bản sao của các vấn đề được gắn 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à thông báo cho bạn nếu sự cố .kt
mới có thể trùng lặp với sự cố được gắn nhãn .java
hiện 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 thành viên dự án đăng ghi chú, ghi chú đó sẽ được gắn nhãn bằng email 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 có bất kỳ vai trò nào sau đây đều có thể xem và xóa các 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 đều có thể xem ghi chú được đăng về 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
Xem Hiểu các chỉ số 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 thành viên dự án đăng ghi chú, ghi chú đó sẽ được gắn nhãn bằng email 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 có bất kỳ vai trò nào sau đây đều có thể xem và xóa các 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 đều có thể xem ghi chú được đăng về 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ó thể trình bá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 lệnh disableSDKCrashReporting
.
Sau khi bạn liên kết Crashlytics với BigQuery, các tập dữ liệu mới mà bạn tạo sẽ tự động được đặt tại Hoa Kỳ, bất kể vị trí 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ố đã tái diễn. Crashlytics tự động mở lại các sự cố đã khắc phục 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.
Sau đâ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ề Crash "A". Crashlytics mở ra 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ề Vấn đề "A" sau khi bạn đóng vấn đề.
- Nếu báo cáo đến từ một phiên bản ứng dụng mà Crashlytics đã biết khi bạn khắc phục sự cố (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 khắc phục. 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 khắc phục và sẽ mở lại sự cố .
Khi sự cố được khắc phục, chúng tôi sẽ gửi cảnh báo phát hiện hồi quy và thêm tín hiệu hồi quy cho sự cố đó để cho bạn biết rằng Crashlytics đã mở lại sự cố. Nếu bạn không muốn sự cố xảy ra lại do thuật toán hồi quy của chúng tôi, hãy "tắt tiếng" sự cố thay vì đóng nó.
Nếu 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 vấn đề thì Crashlytics sẽ coi vấn đề đó đã được khắc phục và sẽ mở lại vấn đề.
Tình huống này có thể xảy ra trong trường hợp sau: Bạn đã sửa một 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à chưa 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 phải lỗi thì những báo cáo sự cố đó sẽ gây ra sự cố đã được khắc phục.
Nếu bạn không muốn sự cố xảy ra lại do thuật toán hồi quy của chúng tôi, hãy "tắt tiếng" sự cố thay vì đóng nó.