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

Xem 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ể 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. Ngoài ra, có thể bạn cũng thấy một tính năng tên là "biến thể" trong một số vấn đề của bạn. Dưới đâ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 để nhóm các sự kiện thành cũng như thiết kế được cập nhật 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 để biết tất cả thông tin chi tiết, nhưng bạn có thể đọc bên dưới để biết những điểm 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ự kiện không nghiêm trọng, và ANR) và tạo nhóm sự kiện được gọi là vấn đề — tất cả sự kiện trong một đều có một điểm chung là lỗi.

Để 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à nền tảng hoặc loại lỗi khác đặc điểm.

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. Một dấu vết ngăn xếp khác có thể là một 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 tạo biến thể trong các vấn đề – mỗi biến thể là một nhóm sự kiện con 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 vấn đề và xác định xem nhiều nguyên nhân gốc khác nhau đều dẫn đến lỗi.

Sau đây là những trải nghiệm của bạn với những điểm cải tiến này:

• Siêu dữ liệu đã sửa đổi và xuất hiện trong hàng về 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.

• Gỡ lỗi dễ dàng hơn cho các vấn đề phức tạp với nhiều nguyên nhân gốc
  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 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 ra là một lỗi mới.

• Tính năng tìm kiếm hiệu quả hơn
  Mỗi số phát hành đều chứa siêu dữ liệu dễ tìm kiếm hơn, như loại ngoại lệ và tên gói.

Dưới đây là cách thức triển khai những 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 một sự kiện hiện có hay không vấn đề.

• Nếu không có kết quả phù hợp, chúng tôi sẽ tự động áp dụng tính năng nhóm sự kiện thông minh hơn thuật toán cho sự kiện và tạo vấn đề mới với siêu dữ liệu được cải tiến thiết kế của bạn.

Đây là lần cập nhật quan trọng đầu tiên mà chúng tôi thực hiện đối với nhóm sự kiện. 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 gửi báo cáo.

Không thấy chỉ số và/hoặc cảnh báo về tốc độ không gặp sự cố

Nếu bạn không thấy những chỉ số không có sự cố (như số người dùng và số phiên không gặp sự cố) và/hoặc cảnh báo vận tốc, hãy đảm bảo rằng bạn đang sử dụng Crashlytics SDK 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 bạn không thấy nhật ký breadcrumb (tập hợp liên kết phân cấp), 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:

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

• 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 Quản lý chế độ cài đặt chia sẻ dữ liệu Analytics

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

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

  Đặc biệt, hãy kiểm tra để chắc chắn rằng bạn đang sử dụng tối thiểu phiên bản sau của Firebase SDK cho Google Analytics:
  Android — phiên bản 17.2.3 trở lên (BoM phiên bản 24.7.1 trở lên).

Tại sao chỉ lỗi ANR đã báo cáo cho Android 11 trở lên không?

Crashlytics hỗ trợ báo cáo ANR cho ứng dụng Android từ thiết bị chạy Android 11 trở lên. API cơ bản mà chúng tôi dùng để thu thập lỗi ANR (gethistoryProcessExitReasons) đáng tin cậy hơn so với các phương pháp dựa trên bộ đếm giờ phòng hoặc SIGQUIT. API này là chỉ có trên các thiết bị chạy Android 11 trở lên.

Lý do thiếu một số lỗi ANR BuildId của họ không?

Nếu một số lỗi ANR của bạn thiếu BuildId, hãy khắc phục như sau:

• Đảm bảo rằng bạn đang sử dụng SDK Android Crashlytics mới nhất và Phiên bản trình bổ trợ Gradle Crashlytics.

  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 dùng một SDK, trình bổ trợ Gradle lỗi thời hoặc cả hai. Để thu thập đúng cách BuildId cho những lỗi ANR này, bạn cần sử dụng các phương thức sau phiên bản:

  • 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)
  • 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 một 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ể mà bạn không sử dụng vị trí chuẩn, mặc định cho thư viện chia sẻ. Nếu trong trường hợp này, thì Crashlytics có thể không tìm được BuildId được liên kết. Bạn nên cân nhắc việc sử dụng phiên bản dành cho thư viện dùng chung.

• Hãy đảm bảo rằng bạn không xoá BuildId trong quá trình xây dựng.

  Xin lưu ý rằng những mẹo khắc phục sự cố sau đây áp dụng cho cả lỗi ANR và ứng dụng gốc sự 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 của bạn. Nếu không có BuildId, sau đó thêm -Wl,--build-id vào cờ cho hệ thống xây dựng.

  • Kiểm tra để đảm bảo rằng bạn không vô tình xoá BuildId để giảm kích thước APK.

  • Nếu bạn vẫn tiếp tục dùng các phiên bản thư viện đã rút gọn và không lược bỏ, hãy đảm bảo trỏ đến phiên bản chính xác trong mã của bạn.

Điểm 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. Điều này có thể xảy ra 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 lần tiếp theo sẽ khởi động, trong khi Android Vitals gửi dữ liệu ANR sau khi ANR xảy ra.

Ngoài ra, Crashlytics chỉ hiện lỗi ANR xảy ra trên các thiết bị đang chạy Android 11 trở lên so với Google Play hiển thị lỗi ANR trên các thiết bị có Đã chấp nhận sự đồng ý đối với việc thu thập dữ liệu và Dịch vụ Google Play.

Điểm khác biệt giữa dấu vết ngăn xếp NDK trong trang tổng quan của Crashlytics và logcat

Chuỗi công cụ LLVM và GNU có các phương thức xử lý và mặc định riêng biệt dành cho tuỳ chọn chỉ đọc phân đoạn tệp nhị phân của ứng dụng. Điều này có thể tạo ra 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ờ 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 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 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 không có cờ nào phù hợp với chuỗi công cụ), hãy thử thêm đoạn mã sau vào quy trình tạo thay vào đó:

-fno-omit-frame-pointer

Cách sử dụng tệp nhị phân của trình tạo tệp biểu tượng Breakpad của riêng tôi cho NDK?

Trình bổ trợ Crashlytics 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 (cho 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 mở rộng 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 trong một gồm 2 cách:

• Lựa chọn 1: Chỉ định đường dẫn thông qua firebaseCrashlytics đuôi tệp 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")
        }
      }
    }
  }
  

  các 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 một dòng thuộc tính trong Gradle tệp thuộc tính

  Bạn có thể dùng 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 hoặc cập nhật tệp này theo cách thủ công thông qua dòng lệnh. Ví dụ: để chỉ định đường dẫn thông qua 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 bạn 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 sự cố . Cách khắc phục vấn đề này:

1. Hãy đảm bảo rằng 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 của mình, hãy thử thêm đoạn mã sau vào các quy tắc làm rối mã nguồn của bạn (trong tệp cấu hình DexGuard của bạn):

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

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

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

Để Crashlytics có thể gặp vấn đề với đuôi tệp chính xác, đả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 hướng dẫn sau tài liệu.

Xin 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 vấn đề .kt mới trùng lặp với 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 đó.

Tại sao tôi thấy .kt vấn đề trùng lặp với các vấn đề hiện có .java vấn đề?

Kể từ giữa tháng 12 năm 2021, Crashlytics đã cải thiện dịch vụ hỗ trợ cho ứng dụng sử dụng Kotlin.

Cho đến gần đây, các trình làm rối mã nguồn hiện có không để lộ đuôi tệp, vì vậy Theo mặc định, Crashlytics đã tạo từng vấn đề có đuôi tệp là .java. Tuy nhiên, kể từ Android Gradle 4.2.0, R8 có hỗ trợ đuôi tệp.

Với bản cập nhật này, Crashlytics nay có thể xác định xem từng lớp được dùng trong ứng dụng được viết bằng Kotlin và đưa tên tệp chính xác vào vấn đề của bạn. Các sự cố hiện được phân bổ chính xác cho .kt tệp (nếu phù hợp) nếu ứng dụng của bạn có chế độ thiết lập như 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 khi tính năng làm rối mã nguồn đang bật.

Bởi vì các sự cố mới hiện đã bao gồm đuôi tệp chính xác trong vấn đề chữ ký, bạn có thể thấy vấn đề .kt mới, thực ra chỉ là bản sao của vấn đề hiện có có gắn nhãn .java. Trong bảng điều khiển Firebase, chúng tôi sẽ cố gắng xác định và thông báo với bạn nếu một vấn đề .kt mới có thể là bản sao của một vấn đề vấn đề hiện có được gắn nhãn .java.

Ai có thể xem, viết và xoá ghi chú về một vấn đề?

Tính năng Ghi chú cho phép các thành viên dự án nhận xét về các vấn đề cụ thể kèm theo câu hỏi, trạng thái cập nhật, v.v.

Khi một thành viên trong dự án đăng một ghi chú, ghi chú đó sẽ được gắn nhãn bằng email của tài khoản. Địa chỉ email này sẽ hiển thị cùng với ghi chú cho tất cả dự án thành viên có quyền truy cập để xem ghi chú.

Nội dung sau đây mô tả quyền truy cập cần thiết để xem, ghi và xoá lưu ý:

• Các thành viên dự án có bất kỳ vai trò nào sau đây đều có thể xem và xoá những vai trò hiện có ghi chú và 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ị 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 sự cố nhưng họ không thể xóa hoặc viết ghi chú.

  • Người xem dự án, Trình xem Firebase, Người xem chất lượng, hoặc Trình xem Crashlytics

Số 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ề những chỉ số không có sự cố.

Ai có thể xem, viết và xoá ghi chú về một vấn đề?

Tính năng Ghi chú cho phép các thành viên dự án nhận xét về các vấn đề cụ thể kèm theo câu hỏi, trạng thái cập nhật, v.v.

Khi một thành viên trong dự án đăng một ghi chú, ghi chú đó sẽ được gắn nhãn bằng email của tài khoản. Địa chỉ email này sẽ hiển thị cùng với ghi chú cho tất cả dự án thành viên có quyền truy cập để xem ghi chú.

Nội dung sau đây mô tả quyền truy cập cần thiết để xem, ghi và xoá lưu ý:

• Các thành viên dự án có bất kỳ vai trò nào sau đây đều có thể xem và xoá những vai trò hiện có ghi chú và 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ị 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 sự cố nhưng họ không thể xóa hoặc viết ghi chú.

  • Người xem dự án, Trình xem Firebase, Người xem chất lượng, hoặc Trình xem Crashlytics

Ứng dụng này cũng sử dụng Google Mobile Ads SDK 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, có thể người 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 được xác định tại 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). Chúng tôi không còn hỗ trợ ABI này kể từ NDK r17.

Hồi quy là gì không?

Một vấn đề đã hồi quy khi trước đó bạn đã đóng vấn đề này 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ể hãy xử lý chúng sao cho phù hợp với ứng dụng của bạn.

Dưới đây là một trường hợp ví dụ giải thích cách Crashlytics phân loại một sự 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ở ra một vấn đề tương ứng với sự cố đó (Vấn đề "A").
2. Bạn khắc phục lỗi này nhanh chóng, đóng Vấn đề "A" rồi phát hành phiên bản mới của ứng dụng của bạn.
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à từ một phiên bản ứng dụng mà Crashlytics biết khi bạn đóng vấn đề (tức là phiên bản đã gửi sự cố báo cáo cho bất kỳ sự cố nào), thì Crashlytics sẽ không xem xét vấn đề được rút lại. Vấn đề sẽ vẫn bị đóng.
   • Nếu báo cáo là từ một phiên bản ứng dụng mà Crashlytics không không biết thời điểm bạn giải quyết vấn đề (tức là phiên bản có 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), sau đó Crashlytics sẽ xem xét vấn đề này đã được rút lại và sẽ mở lại vấn đề.

Khi sự cố giảm dần, 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 đối với vấn đề để cho bạn biết rằng Crashlytics đã đã mở lại vấn đề. Nếu bạn không muốn mở lại sự cố do thuật toán hồi quy, "tắt" thay vì đóng vấn đề.

Tại sao tôi thấy bị sụt giảm phiên bản ứng dụng cũ gặp vấn đề gì?

Nếu báo cáo là từ một phiên bản ứng dụng cũ chưa từng gửi bất kỳ báo cáo sự cố nào tại tất cả khi bạn đóng vấn đề, thì Crashlytics sẽ xem xét vấn đề đã hồi quy 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 đã 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 bạn vẫn có người dùng sử dụng các phiên bản cũ hơn mà không cần 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ấ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 phải lỗi thì các báo cáo sự cố đó sẽ kích hoạt sự cố hồi quy.

Nếu bạn không muốn 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" thay vì đóng vấn đề.