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

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

Bạn có thể nhận thấy 2 đị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, 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 đề. Lý do là đây!

Vào đầu năm 2023, chúng tôi đã ra mắt một công cụ phân tích được cải tiến để phân nhóm các sự kiện, cũng như một 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ư các 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, hoặc bạn có thể đọc phần thông tin nổi bật bên dưới.

Crashlytics phân tích tất cả các sự kiện từ ứ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 được gọi là vấn đề – tất cả các sự kiện trong một vấn đề đều có một điểm chung gây ra 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 cải thiện hiện xem xét nhiều khía cạnh của sự kiện, bao gồm cả các khung hình 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ể có nghĩa là một nguyên nhân gốc rễ 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 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 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 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 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ảnh báo và tín hiệu có ý nghĩa hơn
  Một vấn đề mới thực sự là một lỗi mới.

• Tính năng tìm kiếm mạnh mẽ 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 chúng tôi triển khai những điểm 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 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 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 cho tính năng phân 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ý đường dẫn

Nếu bạn không thấy nhật ký đường dẫn (iOS+ | Android | Flutter | Unity), bạn nên kiểm tra cấu hình Google Analytics của ứng dụng. 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

• 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 phiên bản Firebase SDK 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ủa mình (iOS+ | Android | Flutter | Unity).

  Đối với các nền tảng của Apple và ứng dụng Android, đặc biệt là hãy kiểm tra để đảm bảo rằng bạn đang sử dụng tối thiểu phiên bản sau đây của Firebase SDK cho Google Analytics:iOS+ – v6.3.1+ (v8.9.0+ cho macOS và tvOS) |Android – v17.2.3+ (BoM v24.7.1+).

Không thấy cảnh báo 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 có 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 có sự cố (chẳng hạn như số người dùng và số phiên không có 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 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ố 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 một cách rõ ràng vào việc thu thập dữ liệu. Do đó, độ chính xác của các chỉ số không có 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 tham gia này (thay vì tất cả người dùng của bạn). Điều này có nghĩa là các chỉ số về số lượt 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.

  • Nếu đã tắt tính năng thu thập dữ liệu tự động, bạn có thể dùng sendUnsentReports để gửi báo cáo được lưu vào bộ nhớ đệm trên thiết bị đến Crashlytics. Việc sử dụng phương thức này sẽ gửi dữ liệu sự cố đến Crashlytics, nhưng không gửi dữ liệu phiên. Điều này khiến các biểu đồ trên 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 có 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 các chỉ số về tỷ lệ 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 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 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 sẽ xuất hiện 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, viết và xoá ghi chú:

• Thành viên dự án có một trong các vai trò sau có thể xem và xoá các 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ó một trong những vai trò sau đây có thể xem các ghi chú được đăng trên một vấn đề, nhưng họ 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 đề tái phát là gì?

Một vấn đề được xem là đã hồi quy khi bạn đã đóng vấn đề đó trước đây 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 những vấn đề bị 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.

Sau đây là một ví dụ về tình huống 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 một 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ày.
   • Nếu báo cáo đến 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 đề sẽ vẫn ở trạng thái đã đó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ẽ 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" vấn đề thay vì đóng vấn đề.

Tại sao tôi gặp phải các vấn đề hồi quy đối với các phiên bản cũ của ứng dụng?

Nếu báo cáo đến 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 đã khắc phục một 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 trước đó mà không có bản sửa lỗi. Nếu một trong những phiên bản trướ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ì những báo cáo sự cố đó sẽ kích hoạt một vấn đề hồi quy.

Nếu 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" vấn đề thay vì đóng vấn đề.

Thiếu/không tải dSYM lên

Để tải dSYM của dự án lên và nhận được đầu ra chi tiết, hãy kiểm tra những điều sau:

1. Đảm bảo rằng giai đoạn xây dựng của dự án có chứa tập lệnh chạy Crashlytics. Tập lệnh này 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 về cách 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 đang 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 dSYM bị thiếu, 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 sử 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 lựa chọn "Kéo và thả" dựa trên bảng điều khiển trong thẻ dSYM để 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, đối với các UUID được cung cấp trong thẻ dSYMs.

4. Nếu bạn vẫn thấy dSYM bị thiếu hoặc 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 biểu thị không chính xác

Nếu dấu vết ngăn xếp của bạn có vẻ được biểu thị kém, hãy kiểm tra những điều sau:

• Nếu các khung hình trong thư viện của ứng dụng thiếu thông tin tham chiếu đến mã của ứng dụng, hãy đảm bảo rằng -fomit-frame-pointer không được đặt 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 bị thiếu (đối với phiên bản ứng dụng bị ảnh hưởng) trong thẻ Crashlytics dSYM 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 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 dSYM này lên sẽ không biểu thị các sự cố đã xảy ra, nhưng sẽ giúp đảm bảo biểu thị cho các sự cố trong tương lai.

Tôi có thể 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. Đảm bảo bạn đưa phiên bản 8.9.0 trở lên của Firebase SDK cho Google Analytics vào để các sự cố có thể truy cập vào những chỉ số do Google Analytics thu thập (số người dùng không gặp sự cố, bản phát hành mới nhất, cảnh báo tốc độ và nhật ký đường dẫn).

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 duy nhất, ngay cả khi các ứng dụng được tạo cho nhiều nền tảng 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 chỉ có lỗi ANR được báo cáo cho Android 11 trở lên?

Crashlytics hỗ trợ báo cáo lỗi ANR cho các ứng dụng Android trên những 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 (getHistoricalProcessExitReasons) đáng tin cậy hơn so với các phương pháp dựa trên SIGQUIT hoặc watchdog. 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 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 Crashlytics SDK Android và Crashlytics trình bổ trợ Gradle mới nhất.

  Nếu 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 SDK, trình bổ trợ Gradle hoặc cả hai phiên bản đã lỗi thời. Để thu thập đúng 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 một vị trí không chuẩn cho các thư viện dùng chung của mình hay không.

  Nếu bạn chỉ thiếu BuildId cho các 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 các thư viện dùng chung. Nếu đây là trường hợp này, thì Crashlytics có thể không xác định đượ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 các thư viện dùng chung.

• Đảm bảo rằng bạn không xoá các BuildId trong quy 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 các 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á các BuildId trong nỗ lực giảm kích thước tệp APK.

  • Nếu bạn giữ lại cả phiên bản đã gỡ bỏ và chưa gỡ 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 lỗi ANR trong trang tổng quan Crashlytics và Google Play Console

Có thể có sự khác biệt về 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 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 lần 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ị các lỗi ANR xảy ra trên những 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 những thiết bị có Dịch vụ Google Play và đã chấp nhận 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ã không hiển thị phần mở rộng của tệp, Crashlytics sẽ tạo từng vấn đề có phần mở rộng của tệp là .java theo mặc định.

Để Crashlytics có thể tạo các 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 như 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 đề .kt trùng lặp với các vấn đề .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 chương trình làm rối mã nguồn có sẵn không hiển thị phần mở rộng của tệp, vì vậy, Crashlytics đã tạo 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ợ các tiện ích 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ý vấn đề. Giờ đây, sự cố sẽ được quy cho các tệp .kt một cách chính xác (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 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ể là bản sao của một vấn đề hiện có được gắn nhãn .java.

Không gặp sự cố với 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 khiến ứ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 có 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 các 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ợ Crashlytics Gradle là một phiên bản chính (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 sẽ giải quyết các vấn đề với 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ợ Crashlytics Gradle phiên bản 3 có các yêu cầu tối thiểu sau:

• Trình bổ trợ Android cho Gradle 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.

• Trình bổ trợ Gradle google-services 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 trình bổ trợ Gradle Crashlytics phiên bản 3, tiện ích Crashlytics có những thay đổi có thể gây lỗi sau:

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

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

• Xoá trường strippedNativeLibsDir không dùng nữa. Thay vào đó, bạn nên dùng unstrippedNativeLibsDir cho tất cả các thư viện gốc.

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

  Xem ví dụ có 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 biểu tượng trong MY/NATIVE/LIBS lên, nhưng uploadCrashlyticsSymbolFilesFeatureXRelease sẽ tải các biểu tượng trong cả MY/NATIVE/LIBS và MY/FEATURE_X/LIBS lên.

• Thay thế trường đóng symbolGenerator bằng 2 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 chế độ ghi đè nhị phân dump_syms cục bộ.

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

LLVM và chuỗi công cụ 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 các 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 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 trong chuỗi công cụ GNU, hãy thêm:

  -Wl,--rosegment

Nếu bạn vẫn thấy các điểm 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 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 trình tạo tệp biểu tượng Breakpad của riêng tôi cho NDK?

Trình bổ trợ Crashlytics đi kèm với 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 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")
        }
      }
    }
  }

  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 tệp thuộc tính Gradle

  Bạn có thể 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 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:

  ./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). Chúng tôi đã ngừng hỗ trợ ABI này kể từ NDK r17.

Xem dấu vết ngăn xếp chưa được biểu thị cho các ứng dụng Android trong trang tổng quan Crashlytics

Nếu bạn đang sử dụng Unity IL2CPP 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 bạn đang sử dụng phiên bản 8.6.1 trở lên của Crashlytics Unity SDK.

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 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 biểu thị bằng ký hiệu 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 biểu thị bằng ký hiệu cho các ứng dụng của bạn sử dụng IL2CPP. Tính năng này có sẵn cho các ứng dụng phát hành trên nền tảng Android hoặc Apple. Sau đây là những việc bạn cần làm:

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

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 Apple: Bạn không cần thực hiện hành động đặc biệt nào. Đối với các ứng dụng nền tảng 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à đ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 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 biểu thị bằng ký hiệu 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 trường hợp ngoại lệ chưa được xử lý dưới dạng 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 dưới dạng lỗi nghiêm trọng, bạn sẽ có được thông tin thực tế hơn về những ngoại lệ có thể khiến trò chơi không 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 các 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 với ứng dụng của bạn.

Những trường hợp ngoại lệ nào sẽ được báo cáo là lỗi nghiêm trọng?

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

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

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

Sau khi bật tính năng báo cáo các ngoại lệ chưa được xử lý 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 những 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 xử lý dưới dạng lỗi nghiêm trọng, sau đây là một số lựa chọn để xử lý các ngoại lệ chưa được xử lý này:

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

Phát hiện và xử lý các ngoại lệ được gửi

Các trường hợp 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 bất thường. Để giải quyết các vấn đề được phản ánh bằng một ngoại lệ đã được tạo, bạn cần đưa chương trình về một trạng thái đã biết (một quy trình được gọi là xử lý ngoại lệ).

Bạn nên bắt và xử lý tất cả các trường hợp ngoại lệ dự kiến, trừ phi chương trình không thể trở về trạng thái đã biết.

Để kiểm soát những loại ngoại lệ nào được mã nào bắt và xử lý, hãy gói mã có thể tạo ra ngoại lệ trong một khối try-catch. Đả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 lại các trường hợp 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 nhằm giúp gỡ lỗi.

Khi sử dụng Crashlytics, bạn nên dùng 2 lựa chọn phổ biến nhất sau đây:

• Cách 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 vào bảng điều khiển Unity bằng cách dùng Debug.Log(exception), Debug.LogWarning(exception) và Debug.LogError(exception). Các hàm này in nội dung của trường hợp ngoại lệ vào bảng điều khiển Unity và không gửi lại trường hợp 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 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 phải báo cáo một ngoại lệ cho Crashlytics mặc dù đã được phát hiện và xử lý, thì hãy dùng Crashlytics.LogException(exception) để ghi nhật ký 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 một sự kiện nghiêm trọng cho Unity Cloud Diagnostics theo cách thủ công, 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 đưa ra ngoại lệ (cho dù ngoại lệ đã được đưa ra hay chưa). Thao tác này sẽ tạo ra lỗi không cục bộ. Điều này có nghĩa là ngay cả một Debug.LogException(exception) xung quanh với các khối try-catch vẫn dẫn đến một ngoại lệ chưa đượ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 thao tá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 một sự kiện nghiêm trọng.
• Để gửi ngoại lệ, hãy coi ngoại lệ đó là một ngoại lệ chưa được phát hiện và báo cáo ngoại lệ đó cho Unity Cloud Diagnostics.

Xin lưu ý rằng nếu bạn muốn in một ngoại lệ đã bắt được 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ó thể các 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?

Firebase xuất dữ liệu đến 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í của dữ liệu được lưu trữ để 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 đó nữa. 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 ngày 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 Crashlytics vào BigQuery.

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

Những điểm khác biệt quan trọng giữa cơ sở hạ tầng xuất cũ và cơ sở hạ tầng xuất mới

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

  • Đã bật tính năng xuất trước giữa tháng 10 năm 2024 và đã nâng cấp lên cơ sở hạ tầng xuất dữ liệu mới – Giờ đây, bạn có thể thay đổi vị trí xuất dữ liệu (không bắt buộc).

  • Đã bật tính năng xuất dữ liệu từ giữa tháng 10 năm 2024 trở đi – Bạn được nhắc chọn 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 điền lại 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 lại 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 lại 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 sẽ đặt tên cho các bảng theo lô BigQuery bằng cách sử dụng các 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.

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

Nếu tên bảng lô cũ của bạn 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 này để 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 sử dụng các giá trị nhận dạng để ghi dữ liệu vào các bảng BigQuery

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

• Cơ sở hạ tầng xuất 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 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.

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. Điều này thường xảy ra nếu người dùng 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, thì có nghĩa là:

• Giờ đây, dữ liệu Crashlytics của bạn sẽ được ghi vào một bảng hàng loạt BigQuery mới, 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ó có tên dựa trên mã nhận dạng trong tệp nhị phân của ứng dụng sẽ không còn dữ liệu được ghi 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 hàng loạt 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 mã nhận dạng trong tệp nhị phân của ứng dụng khớp với một trong các mã 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 một bảng mới cho mã nhận dạng đó. Thay vào đó, nó sẽ tiếp tục ghi dữ liệu cho ứng dụng cụ thể đó vào bộ nhớ. Tất cả các ứng dụng khác sẽ được ghi vào các 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 bộ giá trị nhận dạng 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 đó, nó sẽ duy trì bảng đó và bắt đầu ghi dữ liệu cho tất cả các ứng dụng vào bảng đó.}

Các lựa chọn giúp giảm thiểu tình trạng 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 nào ở hạ nguồn 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 hàng loạt 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 do quá trình nâng cấp cơ sở hạ tầng tạo ra để 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 phần 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 đè các 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 đây là tên của bảng cũ mà ứng dụng đã ghi bằng cơ sở hạ tầng xuất cũ).

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

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

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