Câu hỏi thường gặp và cách khắc phục sự cố liên quan đến Giải pháp gửi thông báo qua đám mây của Firebase

Trình soạn thông báo và FCM khác nhau như thế nào?

Firebase Cloud Messaging cung cấp một bộ tính năng nhắn tin hoàn chỉnh thông qua SDK ứng dụng và giao thức máy chủ HTTP. Đối với các hoạt động triển khai có yêu cầu nhắn tin phức tạp hơn, FCM là lựa chọn phù hợp.

Trình soạn thông báo là một giải pháp nhắn tin gọn nhẹ, không máy chủ, được xây dựng trên Firebase Cloud Messaging. Với bảng điều khiển đồ hoạ thân thiện với người dùng và yêu cầu lập trình ít hơn, Trình soạn thông báo cho phép người dùng gửi thông báo để thu hút lại và giữ chân người dùng, thúc đẩy tăng trưởng ứng dụng và hỗ trợ các chiến dịch tiếp thị.

Tôi có cần sử dụng các dịch vụ khác của Firebase để dùng FCM không?

Bạn có thể sử dụng Firebase Cloud Messaging dưới dạng một thành phần độc lập mà không cần dùng các dịch vụ khác của Firebase.

Tại sao các thiết bị mục tiêu của tôi dường như không nhận được thông báo?

Khi có vẻ như thiết bị chưa nhận được thông báo, trước tiên, hãy kiểm tra hai nguyên nhân có thể xảy ra sau đây:

Xử lý thông báo trên nền trước cho thông báo. Ứng dụng khách cần thêm logic xử lý thông báo để xử lý thông báo khi ứng dụng chạy ở nền trước trên thiết bị. Xem thông tin chi tiết cho iOS và Android.

Các quy định hạn chế của tường lửa mạng. Nếu tổ chức của bạn có tường lửa hạn chế lưu lượng truy cập đến hoặc đi từ Internet, thì bạn cần định cấu hình tường lửa đó để cho phép kết nối với FCM nhằm giúp các ứng dụng khách Firebase Cloud Messaging của bạn nhận được thông báo. Các cổng cần mở là:

• 5228
• 5229
• 5230

FCM thường sử dụng cổng 5228, nhưng đôi khi cũng sử dụng cổng 5229 và 5230. FCM không cung cấp địa chỉ IP cụ thể, vì vậy, bạn nên cho phép tường lửa chấp nhận các kết nối đi đến tất cả địa chỉ IP có trong các khối IP được liệt kê trong ASN 15169 của Google.

Tại sao onMessageReceived không được gọi trong ứng dụng Android của tôi?

Khi ứng dụng của bạn ở chế độ nền, thông báo sẽ xuất hiện trong khay hệ thống và onMessageReceived không được gọi. Đối với thông báo có tải trọng dữ liệu, thông báo sẽ xuất hiện trong khay hệ thống và dữ liệu có trong thông báo có thể được truy xuất từ ý định được khởi chạy khi người dùng nhấn vào thông báo.

Để biết thêm thông tin, hãy xem bài viết Nhận và xử lý thông báo.

Tại sao tôi gặp lỗi 404 khi gửi thông báo đến một phiên bản ứng dụng đang hoạt động được khôi phục từ bản sao lưu?

FID (Mã cài đặt Firebase) là giá trị nhận dạng của một phiên bản ứng dụng. Theo mặc định, dữ liệu Cài đặt Firebase sẽ được sao lưu và khôi phục. Vì vậy, trong trường hợp khôi phục, phiên bản ứng dụng được khôi phục và phiên bản ứng dụng gốc sẽ có cùng FID. Vì FCM chỉ lưu trữ một mã thông báo cho mỗi FID, nên nếu cả phiên bản ứng dụng gốc và phiên bản ứng dụng được khôi phục đều đang được sử dụng, thì khi một phiên bản ứng dụng đăng ký với FCM, mã thông báo của phiên bản ứng dụng kia sẽ bị xoá, gây ra lỗi 404.

Nhà phát triển nên làm những việc sau trong ứng dụng của mình:

• Loại trừ dữ liệu cài đặt Firebase trong bản sao lưu. Dữ liệu cài đặt Firebase được lưu trữ trong tệp PersistedInstallation....json. Tên tệp là một hằng số cho một ứng dụng. Ví dụ: <exclude domain="file" path="PersistedInstallation.W0R...GQ.json" />

Apple đã thông báo rằng họ sẽ ngừng sử dụng giao thức nhị phân cũ cho APN. Tôi có cần làm gì không?

Không. Firebase Cloud Messaging đã chuyển sang giao thức APN dựa trên HTTP/2 vào năm 2017. Nếu đang sử dụng FCM để gửi thông báo đến thiết bị iOS, thì bạn không cần làm gì cả.

Làm cách nào để thông báo cho một lượng lớn khách hàng trong vòng 2 phút?

Trường hợp sử dụng này không được hỗ trợ. Bạn phải phân bổ lưu lượng truy cập trong 5 phút.

Ứng dụng của tôi thông báo cho người dùng về các sự kiện và những thông báo này phải được gửi ngay lập tức để hỗ trợ mô hình kinh doanh của tôi. Tôi có thể tăng hạn mức không?

Rất tiếc, chúng tôi không thể tăng hạn mức vì lý do này. Bạn phải phân bổ lưu lượng truy cập trong 5 phút để tránh lưu lượng truy cập tăng đột biến.

Tin nhắn của tôi là về các sự kiện đã lên lịch. Làm cách nào để gửi tất cả lưu lượng truy cập vào đầu giờ?

Bạn nên bắt đầu gửi thông báo ít nhất 5 phút trước khi sự kiện diễn ra. Ngoài ra, hãy gửi thông báo dữ liệu và triển khai trình xử lý tương tự của nền tảng cho onMessageReceived để lên lịch thông báo cục bộ trước thời hạn.

Làm cách nào để theo dõi mức sử dụng hạn mức?

Xem hướng dẫn của Google Cloud về cách lập biểu đồ và theo dõi các chỉ số hạn mức.

Lỗi 429 rất khó để tôi và doanh nghiệp của tôi xử lý. Tôi có thể được miễn trừ hoặc tăng hạn mức để tránh gặp lỗi 429 không?

Mặc dù hiểu rằng hạn mức có thể gây khó khăn, nhưng hạn mức là yếu tố quan trọng để duy trì độ tin cậy của dịch vụ và chúng tôi không thể miễn trừ. Sử dụng cơ chế thử lại để xử lý lỗi 429 đúng cách.

Mất bao lâu thì yêu cầu tăng hạn mức của tôi mới được thực hiện?

Yêu cầu tăng hạn mức của bạn phụ thuộc vào việc bạn sử dụng FCM. Trong mọi trường hợp, bạn có thể nhận được câu trả lời trong vòng vài ngày làm việc. Trong một số trường hợp, có thể có một số thông tin qua lại liên quan đến việc bạn sử dụng FCM và nhiều trường hợp khác, điều này có thể kéo dài quy trình. Nếu tất cả các yêu cầu đều được đáp ứng, thì hầu hết các yêu cầu sẽ được xử lý trong vòng 2 tuần.

Tôi có thể nhận thêm hạn mức cho một sự kiện tạm thời không?

Bạn có thể yêu cầu thêm hạn mức để hỗ trợ một sự kiện kéo dài tối đa 1 tháng. Hãy gửi yêu cầu ít nhất 1 tháng trước khi sự kiện diễn ra và cung cấp thông tin chi tiết rõ ràng về thời điểm bắt đầu và kết thúc sự kiện. FCM sẽ nỗ lực hết sức để đáp ứng yêu cầu đó. Nếu được cấp, các mức tăng hạn mức này sẽ được hoàn nguyên sau ngày kết thúc sự kiện.

Hạn mức hiện tại của tôi có thể thay đổi không?

Mặc dù Google sẽ không làm như vậy một cách dễ dàng, nhưng hạn mức có thể được thay đổi khi cần thiết để bảo vệ tính toàn vẹn của hệ thống. Khi có thể, Google sẽ thông báo trước cho bạn về những thay đổi đó. Luôn cập nhật thông tin liên hệ trong Cloud MSA để tăng cơ hội nhận được thông báo dịch vụ.

Những API và tính năng nào không còn được dùng nữa và sẽ ngừng hoạt động? Tôi nên làm gì nếu đang sử dụng các API này?

Tất cả API máy chủ InstanceId và tính năng nhóm thiết bị đều không còn được dùng nữa và sẽ ngừng hoạt động vào ngày 29 tháng 9 năm 2027. Bảng sau đây trình bày thêm thông tin chi tiết về các API/tính năng không dùng nữa và việc cần làm.

Nếu đang sử dụng SDK của Firebase dành cho quản trị viên để quản lý gói thuê bao theo chủ đề, thì tôi có bị ảnh hưởng khi ngừng sử dụng không? Tôi nên làm gì?

Nếu đang sử dụng các phiên bản cũ của SDK của Firebase dành cho quản trị viên để quản lý gói thuê bao theo chủ đề, thì bạn sẽ chịu ảnh hưởng của việc ngừng cung cấp này. Bạn cần nâng cấp SDK của Firebase dành cho quản trị viên lên các phiên bản sau:

Tôi có bị hạ cấp dịch vụ trước ngày 29 tháng 9 năm 2027 không?

Không. Bạn có 12 tháng để di chuyển từ các API không còn được dùng nữa sang các API thay thế mà không bị hạ cấp dịch vụ. Bạn nên lên kế hoạch di chuyển càng sớm càng tốt để không bị ảnh hưởng khi chúng tôi ngừng cung cấp các tính năng này.

Bạn có thể sẽ gặp lỗi khi gọi các API không dùng nữa sau ngày 29 tháng 9 năm 2027.

Người dùng mới có thể sử dụng các API/tính năng không còn được dùng nữa trước khi ngừng hoạt động không?

Người dùng mới có thể bắt đầu sử dụng các API/tính năng không dùng nữa trước ngày 1 tháng 1 năm 2027. Sau ngày 1 tháng 1 năm 2027, người dùng mới sẽ không thể sử dụng các API không còn được dùng nữa. Những người dùng đang sử dụng các API không dùng nữa có thể tiếp tục sử dụng cho đến ngày 29 tháng 9 năm 2027.

API AndroidConfig (phiên bản 1) cũ sẽ được hỗ trợ trong bao lâu?

FCM dự định tiếp tục hỗ trợ tải trọng phiên bản 1 AndroidConfig trong nhiều năm sau khi phát hành giai đoạn phát hành rộng rãi (GA) AndroidConfigV2. Mặc dù tiến trình di chuyển kéo dài nhiều năm, nhưng AndroidConfigV2 giúp việc gửi thông báo dễ dự đoán hơn và bạn nên di chuyển càng sớm càng tốt.

AndroidConfigV2 hỗ trợ những phiên bản hệ điều hành Android nào?

AndroidConfigV2 sẽ được hỗ trợ trên tất cả các phiên bản Android mà Google hỗ trợ. Tất cả thiết bị (trừ những thiết bị đã dùng hơn 10 năm) sẽ được hỗ trợ khi API v1 cũ ngừng hoạt động.

AndroidConfigV2 có phân phối tải trọng đến các thiết bị chỉ hỗ trợ giao diện v1 cũ không và tôi nên triển khai các thay đổi theo thứ tự nào?

Có. Khi bạn gửi yêu cầu AndroidConfigV2, FCM và GMS Core sẽ tự động dịch tải trọng cho các thiết bị chạy SDK ứng dụng cũ hơn hoặc cho các ứng dụng chưa ghi đè onNotificationReceived() hoặc onBackgroundSyncReceived(), đồng thời phân phối tải trọng đó bằng onMessageReceived().

Tại sao AndroidConfigV2 yêu cầu trả về thông báo thông qua SDK FCM thay vì gọi trực tiếp NotificationManager.notify()?

Bằng cách trả về NotificationResponse cho SDK FCM nguồn mở hoặc sử dụng FcmNotificationManager:

• Ứng dụng của bạn nhận được một cửa sổ thực thi được bảo vệ để giải mã hoặc tuỳ chỉnh thông báo.
• Nếu ứng dụng của bạn hết thời gian, GMS Core sẽ đảm bảo gửi thông báo kịp thời bằng cách đăng thông báo dự phòng mà bạn đã định cấu hình trong remote_notification.notification.

AndroidConfigV2 có xử lý thông báo theo cách khác nhau khi ứng dụng của tôi ở nền trước so với nền sau không?

Không. Không giống như thông báo cũ phiên bản 1, AndroidConfigV2 không phân tách định tuyến thông báo dựa trên việc ứng dụng của bạn đang ở nền trước hay nền sau. Khi bạn gửi RemoteNotification, thông báo sẽ tự động hiển thị ở cả hai trạng thái, trừ phi bạn đặt mutable_content: true và tắt tiếng thông báo một cách rõ ràng trong onNotificationReceived() bằng NotificationResponse.createEmpty().

Ứng dụng của tôi có bao nhiêu thời gian khi xử lý RemoteNotification có thể thay đổi?

Khi mutable_content: true được đặt trên RemoteNotification, ứng dụng của bạn có tối đa 20 giây trong onNotificationReceived() để giải mã tải trọng, tìm nạp các thành phần nhỏ (chẳng hạn như hình đại diện) hoặc liên hệ với máy chủ ứng dụng trước khi trả về NotificationResponse. Nếu lệnh gọi lại vượt quá 20 giây, quá trình thực thi sẽ bị huỷ và GMS Core sẽ tự động đăng thông báo dự phòng dựa trên tải trọng remote_notification.notification.

How does notification suppression enforcement work for mutable RemoteNotifications?

Ứng dụng có thể chặn RemoteNotification bằng cách trả về NotificationResponse.suppress() từ onNotificationReceived(). Ví dụ: khi một cuộc trò chuyện bị tắt tiếng, người gửi bị chặn hoặc tải trọng được mã hoá hai đầu không xác thực được.

• Trong nền: Ứng dụng của bạn có thể chặn tối đa 25% số tin nhắn RemoteNotification nhận được trong một khoảng thời gian luân phiên. Nếu tỷ lệ chặn thông báo trong nền của ứng dụng vượt quá 25%, thì GMS Core sẽ tự động hiển thị và đăng thông báo dự phòng từ tải trọng remote_notification.notification.
• Ở nền trước: Bạn có thể thoải mái chặn tất cả Thông báo từ xa khi đang hoạt động ở nền trước. Ví dụ: để hiển thị thông báo ngắn trong ứng dụng hoặc cập nhật màn hình trò chuyện đang mở thay vì đăng thông báo hệ thống.

Ứng dụng của tôi có thể đăng nhiều thông báo hoặc huỷ một thông báo hiện có từ một RemoteNotification không?

Có. Sử dụng các phương thức sau để huỷ hoặc đăng nhiều thông báo:

• Huỷ một thông báo: Trả về NotificationResponse.createCancel(tag, id) từ onNotificationReceived() để đóng thông báo đã đăng trước đó.
• Đăng nhiều thông báo hoặc kết hợp huỷ và đăng: Gọi getFcmNotificationManager(message) bên trong onNotificationReceived() để gọi postNow(tag, id, notification) và cancelNow(tag, id) nhiều lần, sau đó trả về manager.finished() khi hoàn tất.

RemoteViews tuỳ chỉnh có thể hoạt động với AndroidConfigV2 không?

Có, RemoteViews tuỳ chỉnh sẽ hoạt động với AndroidConfigV2. onNotificationReceived() trả về một đối tượng Notification Android tiêu chuẩn, tất cả các API thông báo Android tiêu chuẩn, chẳng hạn như setCustomContentView(), vẫn được hỗ trợ. Xin lưu ý rằng RemoteViews và Khung hiển thị đang ở chế độ bảo trì và bạn nên di chuyển sang Compose.