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. Bạn cũng có thể thấy một tính năng có tên là "biến thể" trong một số vấ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 để 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 trên blog gần đây của chúng tôi để biết toàn bộ 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ả sự kiện trong ứng dụng của bạn (chẳng hạn như sự cố, lỗi không nghiêm trọng và lỗi ANR) rồi 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ó chung một điểm 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ải tiến hiện 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. Dấu vết ngăn xếp khác nhau có thể cho thấy nguyên nhân gốc khác nhau. Để thể hiện sự khác biệt có thể xảy ra 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 phụ gồm 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 vấn đề và xác định xem các nguyên nhân gốc khác nhau có dẫn đến lỗi hay không.

Sau đâ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 và 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 của mình.

• Í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 cho các vấn đề phức tạp có nhiều nguyên nhân gốc
  Sử dụng các biến thể để gỡ lỗi cho các dấu vết ngăn xếp phổ biến nhất trong một vấn đề.

• Cảnh báo và tín hiệu có ý nghĩa hơn
  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 đề đều 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 những đ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 sự kiện đó có khớp với một vấn đề hiện có 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 một vấn đề mới bằng thiết kế siêu dữ liệu mới.

Đây là bản cập nhật lớn đầu tiên mà chúng tôi thực hiện cho 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 đề, hãy cho chúng tôi biết bằng cách gửi báo cáo.

Không thấy nhật ký dấu vết

Nếu bạn không thấy nhật ký dấu vết (iOS+ | Android | Flutter | Unity), 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 của mình.

• 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ý cài đặt cách chia sẻ dữ liệu Analytics của bạn

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

• Bạn đang sử dụng các phiên bản Firebase SDK mới nhất cho tất cả sản phẩm mà bạn dùng trong ứng dụng của mình (iOS+ | Android | Flutter | Unity).

  Đối với các nền tảng của Apple và ứng dụng Android, hãy đặc biệt kiểm tra để đảm bảo rằng bạn đang sử dụng phiên bản tối thiểu sau đây của Firebase SDK cho Google Analytics: iOS+ — phiên bản 6.3.1 trở lên (phiên bản 8.9.0 trở lên cho macOS và tvOS) | Android — phiên bản 17.2.3 trở lên (BoM phiên bản 24.7.1 trở lên).

Không thấy cảnh báo về tốc độ

Nếu bạn không thấy cảnh báo về tốc độ, hãy đảm bảo rằng bạn đang sử dụng

Không thấy chỉ số không gặp sự cố (hoặc thấy chỉ số không đáng tin cậy)

Nếu bạn không thấy các chỉ số không gặp sự cố (chẳng hạn như người dùng và phiên không gặp sự cố) hoặc thấy các chỉ số không đáng tin cậy, hãy kiểm tra những điều sau:

• Đảm bảo rằng bạn đang sử dụng

• Đảm bảo rằng chế độ cài đặt thu thập dữ liệu không ảnh hưởng đến chất lượng của các chỉ số về tỷ lệ không gặp sự cố:

  • Nếu bạn bật tính năng báo cáo chọn tham gia bằng cách tắt tính năng báo cáo sự cố tự động, thì thông tin về sự cố chỉ có thể được gửi đến Crashlytics từ những người dùng đã chọn tham gia thu thập dữ liệu một cách rõ ràng. Do đó, độ chính xác của các chỉ số không gặp sự cố sẽ bị ảnh hưởng vì Crashlytics chỉ có thông tin về sự cố của những người dùng đã chọn sử dụng (thay vì tất cả người dùng). Điều này có nghĩa là các chỉ số không gặp sự cố có thể kém tin cậy hơn và ít phản ánh độ ổn định tổng thể của ứng dụng hơn.

  • Nếu đã tắt tính năng thu thập dữ liệu tự động, bạn có thể sử dụng sendUnsentReports để gửi báo cáo được lưu vào bộ nhớ đệm trên thiết bị đến Crashlytics. Khi sử dụng phương thức này, dữ liệu sự cố sẽ được gửi đến Crashlytics, nhưng dữ liệu phiên thì không. Điều này khiến biểu đồ trong bảng điều khiển hiển thị giá trị thấp hoặc bằng 0 cho các chỉ số không gặp sự cố.

Số người dùng không gặp sự cố được tính như thế nào?

Xem phần Tìm hiểu về 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 dự án nhận xét về các vấn đề cụ thể bằng 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 email trong Tài khoản Google của họ. Địa chỉ email này sẽ hiển thị cùng với ghi chú 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 về một vấn đề, nhưng không thể xoá hoặc viết ghi chú.

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

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

Một vấn đề đã hồi quy khi bạn đã đóng vấn đề đó trước đây nhưng Crashlytics nhận được 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 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 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ở ra 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à từ 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 đề này sẽ vẫn được đóng.
   • Nếu báo cáo là 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 từng gửi bất kỳ báo cáo sự cố nào cho bất kỳ sự cố nào), thì Crashlytics sẽ coi vấn đề đó là đã hồi quy và sẽ mở lại vấn đề.

Khi một vấn đề tái diễ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 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.

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

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 khi bạn đóng vấn đề, thì Crashlytics sẽ coi vấn đề đó là hồi quy 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 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 các phiên bản cũ hơn mà không có bản sửa lỗi. Nếu một trong những phiên bản cũ hơn chưa từng gửi bất kỳ 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ì những báo cáo sự cố đó sẽ kích hoạt mộ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.

Thiếu dSYM/không tải dSYM lên được

Để tải dSYM của dự án lên và nhận kết quả chi tiết, hãy kiểm tra những thông tin sau:

1. Đảm bảo giai đoạn xây dựng của dự án chứa tập lệnh chạy Crashlytics, cho phép Xcode tải dSYM của dự án lên tại thời điểm xây dựng (đọc phần Khởi chạy Crashlytics để biết hướng dẫn thêm tập lệnh). Sau khi cập nhật dự án, hãy buộc xảy ra sự cố và xác nhận rằng sự cố đó xuất hiện trong trang tổng quan Crashlytics.

2. Nếu bạn thấy cảnh báo "Thiếu dSYM" trong bảng điều khiển Firebase, hãy kiểm tra Xcode để đảm bảo rằng Xcode tạo dSYM đúng cách cho bản dựng.

3. Nếu Xcode đang tạo dSYM đúng cách và bạn vẫn thấy thiếu dSYM, thì có thể công cụ tập lệnh chạy đang bị kẹt trong khi tải dSYM lên. Trong trường hợp này, hãy thử từng cách sau:

   • Đảm bảo bạn đang dùng phiên bản mới nhất của Crashlytics.

   • Tải các tệp dSYM bị thiếu lên theo cách thủ công:

     • Cách 1: Sử dụng tuỳ chọn "Kéo và thả" dựa trên bảng điều khiển trong thẻ dSYMs để tải tệp lưu trữ zip chứa các tệp dSYM bị thiếu lên.
     • Cách 2: Sử dụng tập lệnh upload-symbols để tải các tệp dSYM bị thiếu lên cho các UUID được cung cấp trong thẻ dSYMs.

4. Nếu bạn vẫn thấy thiếu dSYM hoặc vẫn không tải lên được, hãy liên hệ với Nhóm hỗ trợ Firebase và nhớ cung cấp nhật ký của bạn.

Sự cố được thay thế bằng biểu tượng không chính xác

Nếu dấu vết ngăn xếp của bạn có vẻ không được thay thế bằng biểu tượng đúng cách, hãy kiểm tra những điều sau:

• Nếu khung trong thư viện của ứng dụng thiếu tham chiếu đến mã của ứng dụng, hãy đảm bảo rằng bạn không đặt -fomit-frame-pointer làm cờ biên dịch.

• Nếu bạn thấy một số khung (Missing) cho thư viện của ứng dụng, hãy kiểm tra xem có dSYM không bắt buộc nào được liệt kê là bị thiếu (đối với phiên bản ứng dụng bị ảnh hưởng) trong Crashlytics thẻ dSYMs của bảng điều khiển Firebase hay không. Nếu có, hãy làm theo bước khắc phục sự cố "Cảnh báo thiếu dSYM" trong phần Câu hỏi thường gặp về việc thiếu/không tải dSYM lên trên trang này. Xin lưu ý rằng việc tải các tệp dSYM này lên sẽ không thay thế bằng biểu tượng cho các sự cố đã xảy ra, nhưng sẽ giúp đảm bảo thay thế bằng biểu tượng cho các sự cố trong tương lai.

Tôi có thể sử dụng Crashlytics cho macOS hoặc tvOS không?

Có, bạn có thể triển khai Crashlytics trong các dự án macOS và tvOS. Hãy nhớ thêm Firebase SDK phiên bản 8.9.0 trở lên cho Google Analytics để các sự cố có thể truy cập vào những chỉ số do Google Analytics thu thập (người dùng không gặp sự cố, bản phát hành mới nhất, cảnh báo về tốc độ và nhật ký dấu vết).

Tôi có thể sử dụng Crashlytics trong một dự án Firebase có nhiều ứng dụng trên các nền tảng khác nhau của Apple không?

Giờ đây, bạn có thể báo cáo sự cố cho nhiều ứng dụng trong một dự án Firebase, ngay cả khi các ứng dụng đó được xây dựng cho nhiều nền tảng của Apple (ví dụ: iOS, tvOS và Mac Catalyst). Trước đây, bạn cần tách các ứng dụng thành các dự án Firebase riêng lẻ nếu chúng có cùng mã nhận dạng gói.

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 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 cơ chế giám sát. API này chỉ có trên các thiết bị chạy Android 11 trở lên.

Tại sao một số lỗi ANR thiếu BuildId?

Nếu một số lỗi 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 SDK Android Crashlytics và trình bổ trợ Gradle 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 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)
  • Trình bổ trợ Gradle Crashlytics 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 thư viện dùng chung của ứng dụng, thì có thể bạn không sử dụng vị trí mặc định, chuẩn cho thư viện dùng chung. Nếu đúng như vậy, thì Crashlytics có thể không tìm được BuildId 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.

• Đả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ố mã 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 của bạn.

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

  • Nếu bạn giữ 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 đúng phiên bản trong mã của bạn.

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

Có thể có sự khác biệt giữa số lượng lỗi ANR giữa Google Play và Crashlytics. Điều này là bình thường do 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 vào lần tiếp theo ứng dụng khởi động, 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ị các lỗi ANR xảy ra trên thiết bị chạy Android 11 trở lên, so với Google Play hiển thị các lỗi ANR trên thiết bị có Dịch vụ Google Play và đã đồng ý thu thập dữ liệu.

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

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

Để Crashlytics có thể tạo vấn đề với đuôi tệp chính xác, 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 bật tính năng làm rối mã nguồn. Để 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 được 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 đề hiện có về .java. 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 .kt vấn đề trùng lặp với .java vấn đề 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 mã nguồn hiện có không hiển thị đuôi tệp, vì vậy, theo mặc định, Crashlytics đã tạo từng vấn đề có đuôi tệp .java. Tuy nhiên, kể từ Android Gradle 4.2.0, R8 hỗ trợ đ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 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 đề. Sự cố hiện được phân bổ chính xác cho các tệp .kt (nếu phù 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 Gradle 4.2.0 trở lên.
• Ứng dụng của bạn sử dụng R8 khi bật tính năng làm rối mã nguồn.

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 ra chỉ là bản sao của các vấn đề hiện có được gắn nhãn .java. 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 đề mới về .kt có thể trùng lặp với một vấn đề hiện có được gắn nhãn .java.

Không gặp sự cố khi dùng Dexguard

Nếu thấy ngoại lệ sau, có thể bạn đang sử dụng một 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

Làm cách nào để nâng cấp lên trình bổ trợ Gradle Crashlytics phiên bản 3?

Bản phát hành mới nhất của trình bổ trợ Gradle Crashlytics là một phiên bản lớn (phiên bản 3.0.0) và hiện đại hoá SDK bằng cách ngừng hỗ trợ các phiên bản thấp hơn của Gradle và trình bổ trợ Android cho Gradle. Ngoài ra, những thay đổi trong bản phát hành này giúp giải quyết các vấn đề về AGP phiên bản 8.1 trở lên, đồng thời cải thiện khả năng hỗ trợ cho các ứng dụng gốc và bản dựng tuỳ chỉnh.

Yêu cầu tối thiểu

Trình bổ trợ Gradle Crashlytics phiên bản 3 có các yêu cầu tối thiểu sau:

• Trình bổ trợ Android cho Gradle phiên bản 8.1 trở lên
  Nâng cấp trình bổ trợ này bằng Trợ lý nâng cấp trình bổ trợ Android cho Gradle trên phiên bản Android Studio mới nhất.

• google-servicesTrình bổ trợ Gradle 4.4.1 trở lên của Firebase
  Nâng cấp trình bổ trợ này bằng cách chỉ định phiên bản mới nhất trong tệp bản dựng Gradle của dự án, như sau:

plugins {
  id("com.android.application") version "8.1.4" apply false
  id("com.google.gms.google-services") version "4.5.0" apply false
  ...
}

plugins {
  id 'com.android.application' version '8.1.4' apply false
  id 'com.google.gms.google-services' version '4.5.0' apply false
  ...
}

Các thay đổi đối với tiện ích Crashlytics

Với phiên bản 3 của trình bổ trợ Gradle Crashlytics, tiện ích Crashlytics có những thay đổi có thể gây lỗi sau:

• Đã xóa tiện ích khỏi khối android defaultConfig. Thay vào đó, bạn nên định cấu hình từng biến thể.

• Đã xóa trường mappingFile không còn dùng nữa. Thay vào đó, tệp ánh xạ đã hợp nhất hiện được cung cấp tự động.

• Đã xóa trường strippedNativeLibsDir không còn dùng nữa. Thay vào đó, bạn nên sử dụng unstrippedNativeLibsDir cho tất cả thư viện gốc.

• Thay đổi trường unstrippedNativeLibsDir thành tích luỹ.

  Xem ví dụ về nhiều thư mục

  buildTypes {
    release {
      configure<CrashlyticsExtension> {
        nativeSymbolUploadEnabled = true
        unstrippedNativeLibsDir = file("MY/NATIVE/LIBS")
      }
    }
    productFlavors {
      flavorDimensions += "feature"
      create("basic") {
        dimension = "feature"
        // ...
      }
      create("featureX") {
        dimension = "feature"
        configure<CrashlyticsExtension> {
          unstrippedNativeLibsDir = file("MY/FEATURE_X/LIBS")
        }
      }
    }
  }

  Tác vụ uploadCrashlyticsSymbolFilesBasicRelease sẽ chỉ tải các ký hiệu trong MY/NATIVE/LIBS lên, nhưng uploadCrashlyticsSymbolFilesFeatureXRelease sẽ tải các ký hiệu trong cả MY/NATIVE/LIBS và MY/FEATURE_X/LIBS lên.

• Thay thế trường đóng symbolGenerator bằng hai trường cấp cao nhất mới:

  • symbolGeneratorType, một Chuỗi có giá trị là "breakpad" (mặc định) hoặc "csym".
  • breakpadBinary, một Tệp của tệp nhị phân ghi đè cục bộ dump_syms.

Ví dụ về cách nâng cấp tiện ích

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGenerator(
                closureOf<SymbolGenerator> {
                  symbolGeneratorType = "breakpad"
                  breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              )
            }
          }
        }
      

        buildTypes {
          release {
            configure<CrashlyticsExtension> {
              // ...
              symbolGeneratorType = "breakpad"
              breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGenerator {
                breakpad {
                  binary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
                }
              }
            }
          }
        }
      

        buildTypes {
          release {
            firebaseCrashlytics {
              // ...
              symbolGeneratorType "breakpad"
              breakpadBinary file("/PATH/TO/BREAKPAD/DUMP_SYMS")
            }
          }
        }
      

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 giá trị 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, 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 vấn đề 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:

• 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 đi kè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ả 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 tiện ích firebaseCrashlytics trong tệp build.gradle

  Thêm đoạn mã 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 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 qua dòng lệnh. Ví dụ: để chỉ định đường dẫn qua dòng lệnh, hãy sử dụng một 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
  

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ừ NDK r17.

Xem dấu vết ngăn xếp chưa được ký hiệu hoá cho ứng dụng Android trong trang tổng quan Crashlytics

Nếu bạn đang sử dụng IL2CPP của Unity và thấy dấu vết ngăn xếp không được ký hiệu, hãy thử làm như sau:

1. Đảm bảo rằng bạn đang sử dụng SDK Unity Crashlytics phiên bản 8.6.1 trở lên.

2. Đảm bảo rằng bạn đã thiết lập và đang chạy lệnh Firebase CLI crashlytics:symbols:upload để tạo và tải tệp biểu tượng lên.

   Bạn cần chạy lệnh CLI này mỗi khi tạo một bản phát hành hoặc bất kỳ bản dựng nào mà bạn muốn xem dấu vết ngăn xếp được thay thế bằng biểu tượng trong bảng điều khiển Firebase. Tìm hiểu thêm trong bài viết Nhận báo cáo sự cố dễ đọc.

Có thể dùng Crashlytics với các ứng dụng sử dụng IL2CPP không?

Có, Crashlytics có thể hiển thị dấu vết ngăn xếp được thay thế bằng biểu tượng cho các ứng dụng sử dụng IL2CPP. Tính năng này có sẵn cho các ứng dụng được phát hành trên nền tảng Android hoặc Apple. Dưới đây là những việc bạn cần làm:

1. Đảm bảo rằng bạn đang sử dụng SDK Unity Crashlytics phiên bản 8.6.0 trở lên.

2. Hoàn thành các nhiệm vụ cần thiết cho nền tảng của bạn:

   • Đối với ứng dụng trên nền tảng của Apple: Bạn không cần làm gì đặc biệt. Đối với các ứng dụng trên nền tảng của Apple, trình bổ trợ Firebase Unity Editor sẽ tự động định cấu hình dự án Xcode của bạn để tải các biểu tượng lên.

   • Đối với ứng dụng Android: Đảm bảo rằng bạn đã thiết lập và chạy lệnh Firebase CLI crashlytics:symbols:upload để tạo và tải tệp biểu tượng lên.

     Bạn cần chạy lệnh CLI này mỗi khi tạo một bản phát hành hoặc bất kỳ bản dựng nào mà bạn muốn xem dấu vết ngăn xếp được thay thế bằng biểu tượng trong bảng điều khiển Firebase. Tìm hiểu thêm trong bài viết Nhận báo cáo sự cố dễ đọc.

Tại sao ứng dụng nên báo cáo các ngoại lệ chưa được phát hiện là lỗi nghiêm trọng?

Bằng cách báo cáo các ngoại lệ chưa được phát hiện là lỗi nghiêm trọng, bạn sẽ nhận được thông báo thực tế hơn về những ngoại lệ có thể khiến trò chơi không thể chơi được, ngay cả khi ứng dụng tiếp tục chạy.

Xin lưu ý rằng nếu bạn bắt đầu báo cáo lỗi nghiêm trọng, thì tỷ lệ phần trăm người dùng không gặp sự cố (CFU) có thể sẽ giảm, nhưng chỉ số CFU sẽ thể hiện rõ hơn trải nghiệm của người dùng cuối đối với ứng dụng của bạn.

Ngoại lệ nào sẽ được báo cáo là nghiêm trọng?

Để Crashlytics báo cáo một ngoại lệ chưa được phát hiện là nghiêm trọng, bạn phải đáp ứng cả hai điều kiện sau:

• Trong quá trình khởi chạy trong ứng dụng, bạn phải đặt thuộc tính ReportUncaughtExceptionsAsFatal thành true.

• Ứng dụng của bạn (hoặc thư viện đi kèm) gửi một ngoại lệ không được phát hiện. Một ngoại lệ được tạo nhưng không được gửi sẽ không được coi là ngoại lệ chưa được phát hiện.

Sau khi bật tính năng báo cáo các ngoại lệ chưa được phát hiện dưới dạng lỗi nghiêm trọng, giờ đây tôi có nhiều lỗi nghiêm trọng mới. Làm cách nào để xử lý đúng cách các trường hợp ngoại lệ này?

Khi bạn bắt đầu nhận được báo cáo về các ngoại lệ chưa được phát hiện dưới dạng lỗi nghiêm trọng, dưới đây là một số cách để xử lý các ngoại lệ chưa được phát hiện này:

• Hãy cân nhắc cách bạn có thể bắt đầu phát hiện và xử lý các ngoại lệ chưa được phát hiện này.
• Cân nhắc nhiều lựa chọn để ghi lại các ngoại lệ vào bảng điều khiển gỡ lỗi của Unity và vào Crashlytics.

Bắt và xử lý các ngoại lệ được gửi

Các ngoại lệ được tạo và gửi đi để phản ánh các trạng thái không mong muốn hoặc ngoại lệ. Việc giải quyết các vấn đề do ngoại lệ gây ra bao gồm việc đưa chương trình trở lại trạng thái đã biết (một quy trình được gọi là xử lý ngoại lệ).

Tốt nhất là bạn nên phát hiện và xử lý tất cả ngoại lệ có thể dự đoán trước, trừ phi chương trình không thể trở về trạng thái đã biết.

Để kiểm soát loại ngoại lệ nào được mã nào phát hiện và xử lý, hãy gói mã có thể tạo ngoại lệ trong một khối try-catch. Hãy đảm bảo rằng các điều kiện trong câu lệnh catch càng hẹp càng tốt để xử lý các trường hợp ngoại lệ cụ thể một cách thích hợp.

Ghi nhật ký ngoại lệ trong Unity hoặc Crashlytics

Có nhiều cách để ghi lại các trường hợp ngoại lệ trong Unity hoặc Crashlytics để giúp gỡ lỗi.

Khi sử dụng Crashlytics, sau đây là hai lựa chọn phổ biến nhất và được đề xuất:

• Lựa chọn 1: In trong bảng điều khiển Unity nhưng không báo cáo cho Crashlytics trong quá trình phát triển hoặc khắc phục sự cố

  • In ra bảng điều khiển Unity bằng cách sử dụng Debug.Log(exception), Debug.LogWarning(exception) và Debug.LogError(exception). Các phương thức này sẽ in nội dung của ngoại lệ ra bảng điều khiển Unity và không gửi lại ngoại lệ.

• Cách 2: Tải lên Crashlytics để báo cáo tổng hợp trong trang tổng quan Crashlytics cho các trường hợp sau:

  • Nếu một ngoại lệ đáng được ghi lại để gỡ lỗi một sự kiện Crashlytics có thể xảy ra sau đó, hãy sử dụng Crashlytics.Log(exception.ToString()).
  • Nếu vẫn cần báo cáo một ngoại lệ cho Crashlytics mặc dù ngoại lệ đó đã được phát hiện và xử lý, hãy sử dụng Crashlytics.LogException(exception) để ghi lại ngoại lệ đó dưới dạng một sự kiện không nghiêm trọng.

Tuy nhiên, nếu muốn báo cáo thủ công một sự kiện nghiêm trọng cho Unity Cloud Diagnostics, bạn có thể sử dụng Debug.LogException. Tuỳ chọn này in ngoại lệ vào bảng điều khiển Unity như Tuỳ chọn 1, nhưng cũng gây ra ngoại lệ (cho dù ngoại lệ đó đã được gây ra hoặc phát hiện hay chưa). Nó sẽ gửi lỗi không cục bộ. Điều này có nghĩa là ngay cả khi có một khối Debug.LogException(exception) bao quanh với các khối try-catch, thì vẫn có một ngoại lệ không được phát hiện.

Do đó, hãy gọi Debug.LogException nếu và chỉ khi bạn muốn thực hiện tất cả những việc sau:

• Để in ngoại lệ vào bảng điều khiển Unity.
• Để tải ngoại lệ lên Crashlytics dưới dạng sự kiện nghiêm trọng.
• Để gửi ngoại lệ, hãy coi ngoại lệ đó là ngoại lệ chưa được phát hiện và báo cáo ngoại lệ đó cho Unity Cloud Diagnostics.

Lưu ý rằng nếu bạn muốn in một ngoại lệ đã phát hiện vào bảng điều khiển Unity và tải lên Crashlytics dưới dạng một sự kiện không nghiêm trọng, hãy làm như sau:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}

Ứ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ó khả năng 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 Mobile Ads bằng cách gọi disableSDKCrashReporting.

Tập dữ liệu BigQuery của tôi nằm ở đâu?

Firebase xuất dữ liệu sang vị trí tập dữ liệu mà bạn đã chọn khi thiết lập tính năng xuất dữ liệu sang BigQuery.

• Vị trí này áp dụng cho cả tập dữ liệu Crashlytics và tập dữ liệu phiên Firebase (nếu bạn đã bật tính năng xuất dữ liệu phiên).

• Vị trí này chỉ áp dụng cho dữ liệu được xuất vào BigQuery và không ảnh hưởng đến vị trí lưu trữ dữ liệu để sử dụng trong trang tổng quan Crashlytics của bảng điều khiển Firebase hoặc trong Android Studio.

• Sau khi tạo tập dữ liệu, bạn sẽ không thể thay đổi vị trí của tập dữ liệu đó. Tuy nhiên, bạn có thể sao chép tập dữ liệu sang một vị trí khác hoặc tự di chuyển (tạo lại) tập dữ liệu ở một vị trí khác. Để tìm hiểu thêm, hãy xem bài viết Thay đổi vị trí cho các tệp xuất hiện có.

Bạn gặp vấn đề sau khi nâng cấp lên cơ sở hạ tầng xuất dữ liệu mới cho BigQuery?

Vào giữa tháng 10 năm 2024, Crashlytics đã ra mắt một cơ sở hạ tầng mới để xuất hàng loạt dữ liệu của Crashlytics sang BigQuery.

Kể từ ngày 2 tháng 3 năm 2026, tất cả dự án Firebase đã được tự động nâng cấp lên cơ sở hạ tầng xuất hàng loạt mới.

Sự khác biệt quan trọng giữa cơ sở hạ tầng xuất dữ liệu cũ và cơ sở hạ tầng xuất dữ liệu mới

• Cơ sở hạ tầng mới hỗ trợ Crashlytics vị trí tập dữ liệu bên ngoài Hoa Kỳ.

  • Tính năng xuất dữ liệu được bật trước giữa tháng 10 năm 2024 và được nâng cấp lên cơ sở hạ tầng xuất dữ liệu mới – Giờ đây, bạn có thể tuỳ ý thay đổi vị trí xuất dữ liệu.

  • Tính năng xuất dữ liệu được bật từ giữa tháng 10 năm 2024 trở đi — Bạn được nhắc chọn một vị trí để xuất dữ liệu trong quá trình thiết lập.

• Cơ sở hạ tầng mới không hỗ trợ việc bổ sung dữ liệu từ trước khi bạn bật tính năng xuất.

  • Cơ sở hạ tầng cũ hỗ trợ điền bù dữ liệu tối đa 30 ngày trước ngày bạn bật tính năng xuất.

  • Cơ sở hạ tầng mới hỗ trợ điền bù dữ liệu trong tối đa 30 ngày qua hoặc cho ngày gần đây nhất khi bạn bật tính năng xuất sang BigQuery (tuỳ theo ngày nào gần đây nhất).

• Cơ sở hạ tầng mới đặt tên cho các bảng theo lô BigQuery bằng cách sử dụng giá trị nhận dạng được đặt cho Ứng dụng Firebase trong dự án Firebase của bạn.

  • Cơ sở hạ tầng cũ đã ghi dữ liệu vào các bảng theo lô có tên dựa trên mã nhận dạng gói hoặc tên gói trong tệp nhị phân của ứng dụng.

  • Cơ sở hạ tầng mới ghi dữ liệu vào các bảng theo lô có tên dựa trên mã nhận dạng gói hoặc tên gói được đặt cho các Ứng dụng Firebase đã đăng ký trong dự án Firebase của bạn.

Nếu tên bảng lô cũ không khớp với giá trị nhận dạng Ứng dụng Firebase

Nếu tên bảng lô cũ không khớp với mã nhận dạng gói hoặc tên gói được đặt cho Ứng dụng Firebase đã đăng ký, hãy triển khai một trong các lựa chọn sau để tránh làm gián đoạn thêm dữ liệu lô đã xuất.

Tìm hiểu cách cơ sở hạ tầng xuất dữ liệu sử dụng giá trị nhận dạng để ghi dữ liệu vào bảng BigQuery

Dưới đây là cách hai cơ sở hạ tầng xuất dữ liệu ghi dữ liệu Crashlytics vào bảng lô BigQuery:

• Cơ sở hạ tầng xuất dữ liệu cũ: Ghi dữ liệu vào một bảng có tên dựa trên mã nhận dạng gói hoặc tên gói trong tệp nhị phân của ứng dụng.

• Cơ sở hạ tầng xuất dữ liệu mới: Ghi dữ liệu vào một bảng có tên dựa trên mã nhận dạng gói hoặc tên gói được đặt cho Ứng dụng Firebase đã đăng ký trong dự án Firebase của bạn.

Rất tiếc, đôi khi mã nhận dạng gói hoặc tên gói trong tệp nhị phân của ứng dụng không khớp với mã nhận dạng gói hoặc tên gói được đặt cho Ứng dụng Firebase đã đăng ký trong dự án Firebase của bạn. Điều này thường xảy ra nếu có người không nhập giá trị nhận dạng thực tế trong quá trình đăng ký ứng dụng.

Điều gì sẽ xảy ra nếu vấn đề này không được khắc phục trước khi nâng cấp?

Nếu giá trị nhận dạng ở hai vị trí này không khớp nhau, thì có thể đã xảy ra trường hợp sau:

• Dữ liệu Crashlytics của bạn hiện được ghi vào một bảng lô mới BigQuery — tức là một bảng mới có tên dựa trên mã nhận dạng gói hoặc tên gói được đặt cho Ứng dụng Firebase đã đăng ký trong dự án Firebase của bạn.

• Mọi bảng "cũ" hiện có tên dựa trên giá trị nhận dạng trong tệp nhị phân của ứng dụng sẽ không còn được ghi dữ liệu vào nữa.

Ví dụ về các trường hợp giá trị nhận dạng không khớp

Xin lưu ý rằng tên bảng lô BigQuery sẽ tự động được thêm _IOS hoặc _ANDROID để cho biết nền tảng của ứng dụng.

^{* Nếu giá trị nhận dạng trong tệp nhị phân của ứng dụng khớp với một trong các giá trị nhận dạng được đặt cho một Ứng dụng Firebase, thì cơ sở hạ tầng xuất mới sẽ không tạo bảng mới cho giá trị nhận dạng đó. Thay vào đó, hệ thống sẽ tiếp tục ghi dữ liệu cho ứng dụng cụ thể đó vào tệp. Tất cả các ứng dụng khác sẽ được ghi vào bảng mới.}

^{** Nếu một trong các giá trị nhận dạng trong tệp nhị phân của ứng dụng khớp với giá trị nhận dạng được đặt cho Ứng dụng Firebase, thì cơ sở hạ tầng xuất mới sẽ không tạo bảng mới. Thay vào đó, hệ thống sẽ duy trì bảng đó và bắt đầu ghi dữ liệu cho tất cả ứng dụng vào bảng đó.}

Các phương án giảm thiểu sự gián đoạn

• LỰA CHỌN 1:
  Sử dụng bảng mới do cơ sở hạ tầng xuất mới tạo. Bạn sẽ sao chép dữ liệu từ bảng cũ sang bảng mới.

  1. Trong bảng điều khiển Google Cloud, hãy sao chép tất cả dữ liệu từ bảng cũ sang bảng mới được tạo trong quá trình nâng cấp cơ sở hạ tầng.

  2. Nếu bạn có bất kỳ phần phụ thuộc hạ nguồn nào phụ thuộc vào bảng lô, hãy thay đổi các phần phụ thuộc đó để sử dụng bảng mới.

• LỰA CHỌN 2:
  Định cấu hình lại để ghi vào bảng cũ. Bạn cần ghi đè một số giá trị mặc định trong cấu hình BigQuery để đạt được điều này.

  1. Trong bảng điều khiển Firebase, hãy tìm và ghi lại Mã ứng dụng Firebase (ví dụ: 1:1234567890:ios:321abc456def7890) của ứng dụng có tên và giá trị nhận dạng bảng lô không khớp:
     Chuyển đến phần settings Cài đặt dự án, sau đó chuyển đến thẻ Ứng dụng của bạn để xem tất cả Ứng dụng Firebase và thông tin của các ứng dụng đó.

  2. Trong bảng điều khiển Google Cloud, hãy thay đổi "cấu hình chuyển dữ liệu" mới được tạo bằng bản nâng cấp cơ sở hạ tầng để dữ liệu sẽ ghi vào bảng cũ của bạn:

     1. Chuyển đến BigQuery > Chuyển dữ liệu để xem "cấu hình chuyển dữ liệu".

     2. Chọn cấu hình có nguồn Firebase Crashlytics with Multi-Region Support.

     3. Nhấp vào Chỉnh sửa ở góc trên cùng bên phải.

     4. Trong mục Thông tin chi tiết về nguồn dữ liệu, hãy tìm danh sách cho gmp_app_id và danh sách cho client_namespace.

        Trong BigQuery, Mã ứng dụng Firebase được gọi là gmp_app_id. Theo mặc định, giá trị client_namespace trong BigQuery là mã nhận dạng gói / tên gói duy nhất tương ứng của ứng dụng, nhưng bạn sẽ ghi đè cấu hình mặc định này.

        BigQuery sử dụng giá trị client_namespace cho tên của bảng lô mà mỗi Ứng dụng Firebase được liên kết ghi vào.

     5. Tìm gmp_app_id của Ứng dụng Firebase mà bạn muốn ghi đè chế độ cài đặt mặc định. Thay đổi giá trị client_namespace thành tên của bảng mà bạn muốn Ứng dụng Firebase ghi vào (thường là tên của bảng cũ mà ứng dụng đã ghi vào bằng cơ sở hạ tầng xuất dữ liệu cũ).

     6. Lưu thay đổi về cấu hình.

  3. Lên lịch bổ sung dữ liệu cho những ngày mà bảng cũ của bạn bị thiếu dữ liệu.

  4. Sau khi hoàn tất quá trình điền dữ liệu, hãy xoá bảng mới được cơ sở hạ tầng xuất dữ liệu mới tự động tạo.