Cách khắc phục sự cố và câu hỏi thường gặp về Crashlytics
Trang này cung cấp thông tin 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 tìm thấy nội dung mình cần hoặc cần được 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
Xem nhiều định dạng (và đôi khi là "biến thể") cho một số vấn đề trong bảng Vấn đề
Bạn có thể thấy hai định dạng khác nhau cho các vấn đề được liệt kê trong bảng Vấn đề trong bảng điều khiển của Firebase. Ngoài ra, 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. Dưới đây là lý do!
Đầu 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, cũng như cập nhật thiết kế và một số tính năng nâng cao cho các vấn đề mới (như biến thể!). Hãy xem bài đăng trên blog gần đây của chúng tôi để biết toàn bộ thông tin chi tiết hoặc đọc phần bên dưới để biết những điểm nổi bật.
Crashlytics phân tích mọi sự kiện trong ứng dụng của bạn (như sự cố, sự cố không nghiêm trọng và lỗi ANR) và tạo các nhóm sự kiện gọi là vấn đề – tất cả sự kiện trong một vấn đề đều có một điểm chung là lỗi.
Để nhóm các sự kiện vào những vấn đề này, công cụ phân tích được cải tiến giờ đây sẽ xem xét
nhiều khía cạnh của sự kiện, bao gồm 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 khác của nền tảng hoặc loại lỗi.
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. Một dấu vết ngăn xếp khác có thể dẫn đến nguyên nhân gốc 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 sẽ tạo các biến thể trong các vấn đề – mỗi biến thể là một nhóm con gồm các sự kiện trong một vấn đề có cùng điểm lỗi và một 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 thường gặp nhất trong một vấn đề và xác định xem có nhiều nguyên nhân gốc rễ gây ra lỗi hay không.
Sau đâ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 cải tiến hiển thị trong hàng vấn đề Giờ đây, bạn có thể dễ hiểu và phân loại các vấn đề trong ứng dụng hơn.
Ít vấn đề trùng lặp hơn Thay đổi số dòng không dẫn đến vấn đề mới.
Dễ dàng gỡ lỗi các vấn đề phức tạp do nhiều nguyên nhân gốc rễ Sử dụng các biến thể để gỡ lỗi những dấu vết ngăn xếp phổ biến nhất trong một vấn đề.
Các cảnh báo và tín hiệu có ý nghĩa khác Một vấn đề mới thực chất lại là một lỗi mới.
Khả năng tìm kiếm hiệu quả hơn Mỗi vấn đề đều chứa siêu dữ liệu dễ tìm kiếm hơn, chẳng hạn như loại ngoại lệ và tên gói.
Sau đây là cách triển khai những cải tiến này:
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 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 một vấn đề mới với thiết kế siêu dữ liệu được cải tiến.
Đây là nội dung cập nhật lớn đầu tiên mà chúng tôi thực hiện cho nhóm sự kiện. Nếu bạn có ý kiến 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.
Không thấy
chỉ số không có sự cố và/hoặc cảnh báo về tốc độ
Nếu bạn không thấy các chỉ số không có sự cố (chẳng hạn như phiên và người dùng không gặp sự cố) và/hoặc cảnh báo tốc độ, hãy đảm bảo bạn đang sử dụng
SDK Crashlytics phiên bản 18.6.0 trở lên (hoặc Firebase BoM phiên bản 32.6.0 trở lên).
Không thấy nhật ký breadcrumb (tập hợp liên kết phân cấp)
Nếu không thấy nhật ký đường dẫn, bạn nên kiểm tra cấu hình của ứng dụng cho Google Analytics.
Đảm bảo rằng bạn đáp ứng các yêu cầu sau:
Đặc biệt, hãy kiểm tra để đảm bảo rằng bạn đang sử dụng tối thiểu phiên bản Firebase SDK cho Google Analytics: Android — v17.2.3 trở lên(BoM v24.7.1+).
Tại sao lỗi ANR chỉ được báo cáo cho Android 11 trở lên?
Crashlytics hỗ trợ báo cáo ANR cho các ứng dụng Android trên 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 các lỗi ANR (getLịch sửExitReasons)
đáng tin cậy hơn so với SIGQUIT hoặc phương pháp tiếp cận dựa trên bộ đếm giờ. API này chỉ có trên các thiết bị Android 11 trở lên.
Tại sao một số lỗi ANR lại thiếu BuildId?
Nếu một số lỗi ANR của bạn thiếu BuildId, hãy khắc phục như sau:
Hãy đảm bảo rằng bạn đang sử dụng phiên bản mới nhất của SDK Android Crashlytics và trình bổ trợ Crashlytics cho Gradle.
Nếu bạn thiếu BuildId cho Android 11 và một số lỗi ANR trên Android 12, thì có thể bạn đang sử dụng một SDK, trình bổ trợ Gradle hoặc cả hai đã lỗi thời.
Để thu thập BuildId đúng cách cho những lỗi ANR này, bạn cần sử dụng các phiên bản sau:
SDK Android Crashlytics phiên bản 18.3.5 trở lên (Firebase BoM phiên bản 31.2.2 trở lên)
Trình bổ trợ Crashlytics cho Gradle phiên bản 2.9.4 trở lên
Kiểm tra xem bạn có đang sử dụng vị trí không chuẩn cho thư viện chia sẻ hay không.
Nếu bạn chỉ thiếu BuildId cho các thư viện chia sẻ của ứng dụng, thì có thể
bạn đang không sử dụng vị trí mặc định, tiêu chuẩn cho các thư viện chia sẻ. Trong trường hợp này, Crashlytics có thể không tìm được BuildId được liên kết. Bạn nên cân nhắc sử dụng vị trí chuẩn cho các thư viện dùng chung.
Hãy đảm bảo rằng bạn không loại bỏ BuildId trong quá trình xây dựng.
Xin lưu ý rằng các mẹo khắc phục sự cố sau đây áp dụng cho cả lỗi ANR và sự cố gốc.
Kiểm tra xem các BuildId có tồn tại hay không bằng cách chạy readelf -n trên tệp nhị phân của bạn. Nếu không có BuildId, hãy thêm -Wl,--build-id vào các cờ cho hệ thống xây dựng của bạn.
Hãy kiểm tra để đảm bảo rằng bạn không vô tình loại bỏ BuildId nhằm giảm kích thước tệp APK.
Nếu bạn giữ các phiên bản đã loại bỏ và loại bỏ của thư viện, hãy nhớ trỏ đến đúng phiên bản trong mã của bạn.
Sự khác biệt giữa các báo cáo ANR trong trang tổng quan Crashlytics và Google Play Console
Số lượng lỗi ANR giữa Google Play và Crashlytics có thể không khớp. Điều này là bình thường do có sự khác biệt về cơ chế thu thập và báo cáo dữ liệu ANR. Crashlytics báo cáo lỗi ANR khi ứng dụng khởi động tiếp theo, trong khi Android Vitals gửi dữ liệu ANR sau khi lỗi ANR xảy ra.
Ngoài ra, Crashlytics chỉ cho thấy lỗi ANR xảy ra trên các thiết bị chạy Android 11 trở lên, so với lỗi ANR trên Google Play (ứng dụng này cho thấy lỗi ANR trên các thiết bị mà người dùng đã chấp nhận đồng ý thu thập dữ liệu và Dịch vụ Google Play).
Sự khác biệt
giữa dấu vết ngăn xếp NDK trong trang tổng quan Crashlytics và logcat
Chuỗi công cụ LLVM và GNU có các chế độ xử lý và giá trị mặc định riêng biệt cho phân khúc chỉ có thể đọc của 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 của Firebase. Để giảm thiểu điều này, hãy thêm các cờ trình liên kết sau đây 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 lld trong 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 qua 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 liên quan đến chuỗi công cụ), hãy thử thêm thông tin sau đây vào quy trình xây dựng:
-fno-omit-frame-pointer
Làm cách nào để sử dụng tệp nhị phân của trình tạo tệp biểu tượng Breakpad cho NDK?
Trình bổ trợ Crashlytics bao gồm một trình tạo tệp biểu tượng Breakpad tuỳ 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 biểu tượng 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 bản dựng từ nguồn), hãy sử dụng thuộc tính tiện ích symbolGeneratorBinary không bắt buộc để 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 biểu tượng Breakpad theo một trong 2 cách:
Tuỳ chọn 1: Chỉ định đường dẫn thông qua đuôi firebaseCrashlytics trong tệp build.gradle
Thêm phần sau vào tệp build.gradle.kts cấp ứng dụng:
Trình bổ trợ Gradle phiên bản 3.0.0 trở lên
android {
buildTypes {
release {
configure<CrashlyticsExtension> {
nativeSymbolUploadEnabled = true
// Add these optional fields to specify the path to the executable
symbolGeneratorType = "breakpad"
breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
}
}
}
}
phiên bản trình bổ trợ thấp hơ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")
}
}
}
}
}
Lựa chọn 2: Chỉ định đường dẫn thông qua một dòng thuộc tính trong tệp thuộc tính Gradle
Bạn có thể sử dụng thuộc tính com.google.firebase.crashlytics.breakpadBinary
để 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 này thông qua dòng lệnh. Ví dụ: để chỉ định đường dẫn thông qua dòng lệnh, hãy sử dụng một lệnh như sau:
Tại sao tôi thấy sự cố với các tệp .kt được gắn nhãn là vấn đề .java?
Khi ứng dụng sử dụng trình làm rối mã nguồn không hiển thị đuôi tệp, theo mặc định, Crashlytics sẽ tạo từng vấn đề có đuôi tệp là .java.
Để Crashlytics có thể tạo ra các vấn đề với đúng đuôi tệp, hãy đảm bảo ứng dụng của bạn sử dụng chế độ thiết lập sau:
Sử dụng Android Gradle 4.2.0 trở lên
Sử dụng R8 khi tính năng làm rối mã nguồn đang bật. Để cập nhật ứng dụng lên R8, hãy làm theo tài liệu này.
Xin lưu ý rằng sau khi cập nhật lên chế độ thiết lập như mô tả ở trên, bạn có thể bắt đầu thấy các vấn đề mới về .kt trùng lặp với các vấn đề .java hiện có. Hãy xem phần Câu hỏi thường gặp để tìm hiểu thêm về trường hợp đó.
Tại sao tôi thấy
các vấn đề .kt trùng lặp với các vấn đề
hiện có về .java?
Kể từ giữa tháng 12 năm 2021, Crashlytics cải thiện dịch vụ hỗ trợ cho các ứng dụng sử dụng Kotlin.
Cho đến gần đây, các trình làm rối mã nguồn có sẵn không hiển thị đuôi tệp, vì vậy, Crashlytics tạo từng vấn đề có đuôi tệp là .java theo mặc định.
Tuy nhiên, kể từ Android Gradle 4.2.0, R8 hỗ trợ các đuôi tệp.
Với bản cập nhật này, Crashlytics 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ý của vấn đề. Giờ đây, sự cố sẽ được quy chính xác cho tệp .kt (nếu phù hợp)
nếu ứng dụng có chế độ 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 dùng R8 và tính năng làm rối mã nguồn đang bật.
Vì các sự cố mới hiện bao gồm đuôi tệp chính xác trong chữ ký vấn đề, nên bạn có thể thấy các vấn đề .kt mới thực sự là bản sao của các vấn đề hiện có có nhãn .java. Trong bảng điều khiển của Firebase, chúng tôi cố gắng xác định và thông báo cho bạn nếu một vấn đề .kt mới có thể trùng lặp với một vấn đề có nhãn .java hiện có.
Ai có thể xem, viết và xoá ghi chú về một vấn đề?
Ghi chú cho phép các thành viên của dự án nhận xét về các vấn đề cụ thể thông qua câu hỏi, thông tin 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 địa chỉ email trong Tài khoản Google của họ. Địa chỉ email này (cùng với ghi chú) sẽ hiển thị cho tất cả thành viên của dự án và có quyền xem ghi chú đó.
Nội dung sau đây mô tả quyền truy cập cần thiết để xem, ghi và xoá 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à xoá ghi chú hiện có, cũng như viết ghi chú mới về vấn đề.
Ghi chú cho phép các thành viên của dự án nhận xét về các vấn đề cụ thể thông qua câu hỏi, thông tin 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 địa chỉ email trong Tài khoản Google của họ. Địa chỉ email này (cùng với ghi chú) sẽ hiển thị cho tất cả thành viên của dự án và có quyền xem ghi chú đó.
Nội dung sau đây mô tả quyền truy cập cần thiết để xem, ghi và xoá 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à xoá ghi chú hiện có, cũng như viết ghi chú mới về vấn đề.
Ứng dụng cũng sử dụng
SDK Quảng cáo của Google trên thiết bị di động nhưng không gặp sự cố
Nếu dự án của bạn sử dụng Crashlytics cùng với SDK Quảng cáo của Google trên thiết bị di động,
thì có thể trình báo cáo sự cố sẽ can thiệp khi
đăng ký trình xử lý ngoại lệ. Để khắc phục vấn đề này, hãy tắt tính năng 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.
Tập dữ liệu BigQuery của tôi nằm ở đâu?
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 ở Hoa Kỳ, bất kể vị trí của dự án Firebase.
Hỗ trợ nền tảng
Crashlytics có hỗ trợ armeabi không?
Firebase Crashlytics NDK không hỗ trợ ARMv5 (armeabi).
Kể từ NDK r17, tính năng hỗ trợ ABI này đã bị loại bỏ.
Vấn đề bị hồi quy
Vấn đề hồi quy là gì?
Một vấn đề đã được hồi quy khi trước đó bạn đã đóng vấn đề đó nhưng
Crashlytics nhận được một báo cáo mới cho biết vấn đề đó đã tái diễn.
Crashlytics tự động mở lại các vấn đề đã hồi quy này để bạn có thể giải quyết chúng 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 một vấn đề 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 liên quan đến sự cố đó (Vấn đề "A").
Bạn sẽ nhanh chóng khắc phục lỗi này, đóng Vấn đề "A", sau đó phát hành một phiên bản mới của ứng dụng.
Crashlytics sẽ 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 là của một phiên bản ứng dụng mà Crashlytics đã biết
khi bạn đóng vấn đề (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 vấn đề đó là đã hồi quy. Vấn đề vẫn sẽ đóng.
Nếu báo cáo là của một phiên bản ứng dụng mà Crashlytics không biết khi bạn đóng vấn đề (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 sẽ xem xét vấn đề đã được hồi quy và sẽ mở lại vấn đề.
Khi một vấn đề giảm mức độ, chúng tôi sẽ gửi cảnh báo phát hiện số lần hồi quy và thêm tín hiệu hồi quy vào vấn đề đó để cho bạn biết rằng Crashlytics đã mở lại vấn đề. Nếu bạn không muốn một vấn đề xuất hiện lại do thuật toán hồi quy của chúng tôi, hãy "tắt tiếng" thay vì đóng vấn đề đó.
Tại sao tôi thấy vấn đề bị hồi quy đối với các phiên bản ứng dụng cũ?
Nếu báo cáo là của một phiên bản ứng dụng cũ và chưa từng gửi báo cáo sự cố nào khi bạn đóng vấn đề, thì Crashlytics sẽ xem xét vấn đề được hồi quy và sẽ mở lại vấn đề đó.
Trường hợp này có thể xảy ra trong trường hợp sau: Bạn đã khắc phục lỗi và phát hành một phiên bản mới của ứng dụng, nhưng người dùng của bạn vẫn sử dụng các phiên bản cũ hơn nhưng chưa sửa lỗi đó. Nếu tình cờ, một trong các 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 vấn đề, và những người dùng đó bắt đầu gặp lỗi, thì những báo cáo sự cố đó sẽ kích hoạt một vấn đề được hồi quy.
Nếu bạn không muốn một vấn đề xuất hiện trở lại do thuật toán hồi quy của chúng tôi, hãy "ẩn" vấn đề đó thay vì đóng vấn đề đó.