Khắc phục sự cố và câu hỏi thường gặp về Crashlytics

Thấy các định dạng khác nhau (và đôi khi là "biến thể") cho một số vấn đề trong bảng Vấn đề

Bạn có thể nhận 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 Firebase. Bạn cũng có thể nhận thấy một tính năng có tên là "biến thể" trong một số vấn đề. Sau đây là lý do!

Vào đầu năm 2023, chúng tôi đã ra mắt một công cụ phân tích cải tiến để phân nhóm các sự kiện, cũng như thiết kế mới và một số tính năng nâng cao cho các vấn đề mới (chẳng hạn như biến thể!). Hãy xem bài đăng gần đây trên blog của chúng tôi để biết tất cả thông tin chi tiết. Bạn cũng có thể đọc phần dưới đây để biết thông tin nổi bật.

Crashlytics phân tích tất cả sự kiện trong ứng dụng của bạn (chẳng hạ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 được gọi là vấn đề – tất cả sự kiện trong một vấn đề đều có đ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 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. Dấu vết ngăn xếp khác nhau có thể có nghĩa là nguyên nhân gốc rễ khác nhau. Để thể hiện sự khác biệt có thể có này trong một vấn đề, giờ đây, chúng ta tạo các biến thể trong các vấn đề – mỗi biến thể là một nhóm con sự kiện trong một vấn đề có cùng một đ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 phổ biến nhất trong một vấn đề và xác định xem có nhiều nguyên nhân gốc rễ dẫn đến lỗi hay không.

Dưới đây là những điểm cải tiến mà bạn sẽ thấ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ễ dàng hiểu và phân loại các vấn đề trong ứng dụng.

• Ít vấn đề trùng lặp hơn
  Việc 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 với nhiều nguyên nhân gốc
  Sử dụng biến thể để gỡ lỗi các 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 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 hiệu quả hơn
  Mỗi vấn đề chứa nhiều siêu dữ liệu có thể 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 các điểm cải tiến này:

• 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 các sự kiện đó có khớp với vấn đề hiện có hay không.

• Nếu không có sự 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 một vấn đề mới với thiết kế siêu dữ liệu được cải tiến.

Đây là lần cập nhật lớn đầu tiên mà chúng tôi thực hiện đối với tính năng nhóm sự kiện. Nếu bạn có ý kiến phản hồi hoặc gặp vấn đề, vui lòng cho chúng tôi biết bằng cách gửi báo cáo .

Không thấy các chỉ số về số lần không gặp 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 gặp sự cố (chẳng hạn như số người dùng và số phiên không gặp sự cố) và/hoặc cảnh báo về tốc độ, hãy đảm bảo rằng bạn đang sử dụngSDK 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ý 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. Hãy đảm bảo rằng bạn đáp ứng các yêu cầu sau:

• Bạn đã bật Google Analytics trong dự án Firebase.

• Bạn đã bật tính năng Chia sẻ dữ liệu cho Google Analytics. Tìm hiểu thêm về chế độ cài đặt này trong bài viết Quản lý chế độ cài đặt cách chia sẻ dữ liệu Analytics

• Bạn đã thêm SDK Firebase cho Google Analytics vào ứng dụng của mình. Bạn phải thêm SDK này ngoài ra vào SDK Crashlytics.

• Bạn đang sử dụng các phiên bản SDK Firebase mới nhất cho tất cả các sản phẩm mà bạn sử dụng trong ứng dụng.

  Đặc biệt, hãy kiểm tra để đảm bảo rằng bạn đang sử dụng ít nhất phiên bản SDK Firebase sau đây cho Google Analytics:
  Android — v17.2.3 trở lên (BoM v24.7.1 trở lên).

Tại sao lỗi ANR chỉ được báo cáo cho Android 11 trở lên?

Crashlytics hỗ trợ tính năng báo cáo lỗi 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 lỗi ANR (getHistoricalProcessExitReasons) đáng tin cậy hơn so với các phương pháp dựa trên SIGQUIT hoặc trình giám sát. 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 bị thiếu BuildId?

Nếu một số ANR bị thiếu BuildId, 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 trình bổ trợ Gradle Crashlytics và SDK Android Crashlytics mới nhất.

  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 đúng cách BuildId cho các lỗi ANR này, bạn cần sử dụng các phiên bản sau:

  • Crashlytics SDK Android phiên bản 18.3.5 trở lên (Firebase BoM phiên bản 31.2.2 trở lên)
  • Crashlytics Trình bổ trợ 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 dùng chung 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 không sử dụng vị trí tiêu chuẩn, mặc định cho thư viện dùng chung. Nếu trường hợp này xảy ra, thì Crashlytics có thể không xác định được các BuildId được liên kết. 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 xoá 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 BuildId có tồn tại hay không bằng cách chạy readelf -n trên tệp nhị phân. Nếu không có BuildId, hãy thêm -Wl,--build-id vào cờ cho hệ thống xây dựng.

  • Kiểm tra để đảm bảo bạn không vô tình xoá các BuildId trong nỗ lực giảm kích thước tệp APK.

  • Nếu bạn giữ lại các phiên bản đã loại bỏ và chưa loại bỏ của một thư viện, hãy nhớ trỏ đến phiên bản chính xác trong mã của bạn.

Sự khác biệt giữa báo cáo lỗi ANR trong trang tổng quan Crashlytics và Google Play Console

Số lượng lỗi ANR có thể không khớp giữa Google Play và Crashlytics. Điều này 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 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ỉ hiển thị lỗi 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ị lỗi ANR từ các thiết bị có Dịch vụ Google Play và đã chấp nhận sự đồng ý thu thập dữ liệu.

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ế độ mặc định và cách xử lý riêng biệt cho phân đoạn chỉ đọc của tệp nhị phân trong ứ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 vấn đề này, hãy thêm các cờ trình liên kết sau vào quy trình xây dựng:

• 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 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ụ của bạn), hãy thử thêm nội dung sau 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 đóng gói 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 của trình tạo tệp biểu tượng Breakpad theo một trong hai cách:

• Cách 1: Chỉ định đường dẫn thông qua đuôi firebaseCrashlytics trong tệp build.gradle

  Thêm nội dung 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")
            }
          }
        }
     }
  }

• Cách 2: Chỉ định đường dẫn thông qua 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 qua dòng lệnh. Ví dụ: để chỉ định đường dẫn thông 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.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

Không gặp sự cố với Dexguard

Nếu thấy trường hợp 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 Firebase Crashlytics:

java.lang.IllegalArgumentException: Transport backend 'cct' is not registered

Ngoại lệ này không làm ứng dụng của bạn gặp sự cố nhưng ngăn ứng dụng gửi báo cáo sự cố. Cách khắc phục:

1. Đả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.

2. Nếu bạn không muốn thay đổi phiên bản DexGuard, hãy thử thêm dòng sau vào quy tắc làm rối mã nguồn (trong tệp cấu hình DexGuard):

   -keepresourcexmlelements manifest/application/service/meta-data@value=cct

Tại sao tôi thấy các sự cố từ tệp .kt được gắn nhãn là vấn đề .java?

Theo mặc định, khi một ứng dụng sử dụng trình làm rối mã không hiển thị đuôi tệp, Crashlytics sẽ tạo từng vấn đề có đuôi tệp .java.

Để Crashlytics có thể tạo 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 cho Gradle 4.2.0 trở lên
• Sử dụng R8 với tính năng làm rối mã nguồn được 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 chế độ 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ó. 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 đề về .kt trùng lặp với các vấn đề về .java hiện có?

Kể 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 rối hiện có không hiển thị đuôi tệp, vì vậy, Crashlytics đã tạo từng vấn đề bằng đuôi tệp .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 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à có đưa tên tệp chính xác vào chữ ký lỗi hay không. Giờ đây, các sự cố sẽ được phân bổ chính xác cho các tệp .kt (nếu thích hợp) nếu ứng dụng của bạn có chế độ thiết lập sau:

• Ứng dụng của bạn sử dụng Android cho Gradle 4.2.0 trở lên.
• Ứng dụng của bạn sử dụng R8 với tính năng làm rối mã nguồn đang bật.

Vì các sự cố mới hiện có đ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ự chỉ là bản sao của các vấn đề 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à 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 trong dự án bình luận về các vấn đề cụ thể bằng câu hỏi, thông tin cập nhật về trạng thái, v.v.

Khi một thành viên trong 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ùng với ghi chú sẽ hiển thị cho tất cả thành viên dự án có quyền xem ghi chú.

Phần sau đây mô tả quyền truy cập cần thiết để xem, ghi và xoá ghi chú:

• 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ề một vấn đề.

  • Chủ sở hữu hoặc Người chỉnh sửa dự án, Quản trị viên Firebase, Quản trị viên chất lượng hoặc Quản trị viên Crashlytics

• Thành viên dự án có bất kỳ vai trò nào sau đây đều có thể xem ghi chú được đăng trên một vấn đề, nhưng không thể xoá 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ỷ lệ người dùng không gặp sự cố được tính như thế nào?

Xem bài viết Tìm hiểu về các chỉ số không gặp sự 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 trong dự án bình luận về các vấn đề cụ thể bằng câu hỏi, thông tin cập nhật về trạng thái, v.v.

Khi một thành viên trong 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ùng với ghi chú sẽ hiển thị cho tất cả thành viên dự án có quyền xem ghi chú.

Phần sau đây mô tả quyền truy cập cần thiết để xem, ghi và xoá ghi chú:

• 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ề một vấn đề.

  • Chủ sở hữu hoặc Người chỉnh sửa dự án, Quản trị viên Firebase, Quản trị viên chất lượng hoặc Quản trị viên Crashlytics

• Thành viên dự án có bất kỳ vai trò nào sau đây đều có thể xem ghi chú được đăng trên một vấn đề, nhưng không thể xoá 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

Ứng dụng cũng sử dụng SDK Google Mobile Ads 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 Google Mobile Ads, thì có thể 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 vấn đề này, hãy tắt tính năng báo cáo sự cố trong SDK Mobile Ads 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 nằm ở Hoa Kỳ, bất kể vị trí của dự án Firebase.

Crashlytics có hỗ trợ armeabi không?

NDK Firebase Crashlytics không hỗ trợ ARMv5 (armeabi). Tính năng hỗ trợ cho ABI này đã bị xoá kể từ phiên bản NDK r17.

Vấn đề hồi quy là gì?

Một vấn đề đã hồi quy khi bạn đã đóng vấn đề trước đó nhưng Crashlytics nhận được một báo cáo mới cho biết vấn đề đã tái diễn. Crashlytics sẽ tự động mở lại các vấn đề hồi quy này để bạn có thể giải quyết các vấn đề đó cho phù hợp với ứng dụng của mình.

Dưới đây là một tình huống mẫu giải thích cách Crashlytics phân loại một vấn đề là hồi quy:

1. Lần đầu tiên, Crashlytics nhận được báo cáo sự cố về Sự cố "A". Crashlytics sẽ mở một vấn đề tương ứng cho sự cố đó (Vấn đề "A").
2. Bạn nhanh chóng khắc phục lỗi này, đóng Vấn đề "A" rồi phát hành phiên bản mới của ứng dụng.
3. 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 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 mọi sự cố), thì Crashlytics sẽ không coi vấn đề là hồi quy. Vấn đề này sẽ vẫn được đóng.
   • 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 vấn đề (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 đề đã hồi quy và sẽ mở lại vấn đề.

Khi một vấn đề hồi quy, chúng tôi sẽ gửi một cảnh báo phát hiện hồi quy và thêm một 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 đề mở lại do thuật toán hồi quy của chúng tôi, hãy "tắt tiếng" vấn đề đó thay vì đóng vấn đề.

Tại sao tôi thấy các vấn đề hồi quy đối với các phiên bản ứng dụng cũ?

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áo cáo sự cố nào khi bạn đóng vấn đề, thì Crashlytics sẽ coi vấn đề đó là 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 phiên bản mới của ứng dụng, nhưng vẫn có người dùng sử dụng phiên bản cũ hơn mà không có bản sửa lỗi. Nếu tình cờ một trong những phiên bản cũ đó chưa bao giờ gửi báo cáo sự cố nào khi bạn đóng vấn đề và người dùng bắt đầu gặp lỗi, thì các báo cáo sự cố đó sẽ kích hoạt vấn đề hồi quy.

Nếu bạn không muốn một vấn đề mở lại do thuật toán hồi quy của chúng tôi, hãy "tắt tiếng" vấn đề đó thay vì đóng vấn đề.