Google Play từ chối ứng dụng của bạn vì Broken Functionality? Ý nghĩa và cách khắc phục (2026)

Cập nhật đến ngày 16 tháng 10 năm 2026. Mọi quy định trên trang này đều đã được đối chiếu với các trang chính sách của Google Play và Trợ giúp Play Console vào ngày đó, và mỗi quy định đều có liên kết tại chỗ được dùng. Các báo cáo của nhà phát triển trích dẫn bên dưới là bằng chứng về những gì nhà phát triển đã gặp trong năm 2026, không phải chẩn đoán của Google về ứng dụng của họ, và bài viết không xếp hạng các nguyên nhân vì không có bộ dữ liệu công khai nào hỗ trợ việc đó.

Bài viết này nói về việc bản phát hành bị từ chối theo chính sách Broken Functionality. Nếu Google từ chối cấp quyền truy cập vào kênh phát hành công khai sau thử nghiệm khép kín, hoặc cho biết cần thử nghiệm thêm, thì đó là một quyết định khác với cách sửa khác: thay vào đó, hãy đọc cần làm gì khi Google Play nói cần thử nghiệm thêm và vì sao đơn đăng ký sau thử nghiệm khép kín bị từ chối.

Broken Functionality trên Google Play có nghĩa là gì?

Ngay dưới câu đó, Google liệt kê ba ví dụ về vi phạm thường gặp: ứng dụng không cài được, ứng dụng cài được nhưng không tải, và ứng dụng tải được nhưng không phản hồi. Hãy xem đó là ba chỗ cần kiểm tra. Người xem xét không cài được bản build, người thấy màn hình trống hoặc màn hình tải mãi không xong, hay người chạm vào một nút mà không có gì xảy ra, đều có thể dẫn đến cùng một thông báo.

Bạn vẫn có thể gặp tên Minimum Functionality trong các liên kết Trợ giúp cũ và các chủ đề trên diễn đàn. Phần chính sách hiện tại có tên Limited Functionality and Content, áp dụng cho ứng dụng chỉ chứa văn bản tĩnh hoặc PDF, ứng dụng có rất ít nội dung và ứng dụng được thiết kế để không làm gì cả. Thông báo có thể nêu một trong hai phần, và cách sửa khác nhau, vì vậy hãy đọc xem thông báo của bạn nêu phần nào trước khi thay đổi bất cứ thứ gì.

Bốn quyết định hay bị nhầm lẫn với nhau

Google cho thấy phần bị lỗi ở đâu?

Mở Play Console, chọn ứng dụng và mở trang Policy status của nó. Ghi lại bốn điều trước khi đụng vào mã nguồn: phần chính sách được nêu, mã phiên bản (version code) và kênh đã được xem xét, ngày, và mọi bằng chứng đính kèm. Hãy kiểm tra cả email và thông báo trong Play Console, vì đó là nơi Google nêu rõ bản phát hành đã vi phạm chính sách nào.

Thông báo năm 2026 thực tế trông như thế nào

Không có một email Broken Functionality duy nhất mà ai cũng nhận được, và trang nào in ra một email như thể đó là mẫu chính xác thì đều đang phỏng đoán. Các nhà phát triển công khai thông báo của họ trong năm 2026 mô tả những mức độ chi tiết rất khác nhau:

• Một nhãn thông báo ghi “Broken Functionality: Unresponsive UI elements” (thành phần giao diện không phản hồi), được đăng ngày 2 tháng 9 năm 2026 bởi một nhà phát triển có ứng dụng hiển thị màn hình thử lại khi ngoại tuyến trong lần đồng bộ dữ liệu đầu tiên (Cộng đồng trợ giúp Play Console).
• Một ví dụ của người xem xét ghi “For example, your app does not open or load.” (ví dụ, ứng dụng của bạn không mở hoặc không tải), được một nhà phát triển game trích dẫn vào tháng 6 năm 2026, dù màn hình tiêu đề của game vẫn tải được. Sau đó tác giả cho biết game đã được phát hành sau khi thay đổi cách nút Quay lại (Back) của Android thoát khỏi game.
• Một thông báo mà một nhà phát triển mô tả vào tháng 8 năm 2026 là chỉ có hai từ, “Broken functionality”, ngoài ra không có gì khác.

Đây là các trích đoạn do nhà phát triển chép lại, không phải email đã được xác thực của Google, và mỗi trích đoạn chỉ là một trường hợp. Chúng cho thấy phạm vi mức độ chi tiết bạn có thể nhận được, chứ không cho biết thông báo của bạn sẽ ghi gì hay vì sao ứng dụng của bạn không đạt.

Cần kiểm tra gì trước tiên sau khi bị từ chối vì Broken Functionality?

Năm bước kiểm tra, theo thứ tự

Làm thế nào để cung cấp thông tin đăng nhập cho người xem xét của Google?

Thêm hoặc cập nhật hướng dẫn

1. Mở Play Console và vào trang App content (Policy and programs > App content).
2. Trong mục Sign-in details, chọn Start, hoặc Manage nếu trước đây bạn đã thêm hướng dẫn.
3. Chọn + Add new instructions và nhập thông tin truy cập. Dùng trường Any other instructions cho mọi điều khác thường, chẳng hạn mật khẩu dùng một lần, xác thực đa yếu tố hoặc màn hình đăng nhập có nhiều hơn hai trường.
4. Lưu thay đổi. Bạn có thể thêm tối đa năm bộ hướng dẫn.
5. Vào Publishing overview, tìm thay đổi trong mục Changes ready to send for review, rồi chọn Send for review. Chỉ lưu thôi thì chưa gửi gì cả.

Thế nào là quyền truy cập dùng được

Các yêu cầu đối với Play Console của Google yêu cầu bạn “cung cấp một tài khoản demo đang hoạt động, thông tin đăng nhập và mọi tài nguyên khác cần thiết để Google Play xem xét ứng dụng của bạn”. Các yêu cầu về Sign-in details của Google nói rõ điều đó có nghĩa là gì:

• Một tài khoản đang hoạt động và dùng lại được, không phải lời mời chỉ dùng một lần hay bản dùng thử hết hạn trong lúc xem xét.
• Thông tin đăng nhập vượt qua được mã dùng một lần và xác minh hai bước, vì người xem xét không nhận được mã bạn gửi đến điện thoại hay hộp thư.
• Quyền truy cập dùng được từ mọi vị trí nếu ứng dụng giới hạn theo khu vực, và quyền truy cập đầy đủ vào các tính năng trả phí hoặc bị giới hạn mà người xem xét cần xem, mà không bị tính tiền.
• Thông tin được viết bằng tiếng Anh và luôn được cập nhật. Nếu bạn đổi mật khẩu hoặc xóa tài khoản thử nghiệm, hãy cập nhật Sign-in details ngay trong ngày.
• Nếu việc đăng nhập cần thứ gì đó không phải văn bản, chẳng hạn mã QR hoặc mã vạch, hãy tạo một URL tĩnh cho nó và thêm vào Sign-in details. Nếu ứng dụng yêu cầu người dùng tự đặt mã PIN hoặc dùng đăng nhập qua mạng xã hội, hãy giải thích trong hướng dẫn cách người xem xét vượt qua bước đó.

Nếu ứng dụng chạy tốt trên điện thoại của bạn và Google không gửi ảnh chụp màn hình thì sao?

Báo cáo trước khi ra mắt

Bạn tìm báo cáo này trong Test and release > Testing > Pre-launch report. Google tự động tạo báo cáo khi bạn tải lên một gói ứng dụng hoặc APK, tùy theo năng lực xử lý, bằng cách chạy ứng dụng trên các thiết bị thử nghiệm. Hãy kiểm tra xem quá trình thu thập dữ liệu thực sự đã đến những màn hình nào: nếu nó dừng ở màn hình đăng nhập, nó chưa bao giờ thấy phần còn lại của ứng dụng. Google thêm một giới hạn đáng biết: “Thông tin đăng nhập chỉ có thể được tự động điền vào các ứng dụng Android sử dụng tiện ích Android tiêu chuẩn.” (Sử dụng báo cáo trước khi ra mắt để xác định vấn đề). Một báo cáo không có lỗi là bằng chứng, không phải giấy thông qua. Google cũng nói điều tương tự về các bước kiểm tra trước khi xem xét: “Việc vượt qua mọi bước kiểm tra trước khi xem xét không đảm bảo sẽ vượt qua quy trình xem xét ứng dụng chính thức”.

Android vitals

Bạn tìm dữ liệu này trong Monitor and improve > Android vitals > Crashes and ANRs. Google chỉ thu thập dữ liệu này từ những người dùng đã chọn chia sẻ dữ liệu sử dụng và chẩn đoán (Theo dõi chất lượng kỹ thuật bằng Android vitals), nên một ứng dụng mới trong một đợt thử nghiệm nhỏ có thể không hiển thị gì cả. Trang vitals trống không chứng minh rằng ứng dụng chưa từng gặp sự cố.

Người thật trên thiết bị thật

Thử nghiệm khép kín tồn tại để tìm ra loại vấn đề này trước khi phát hành công khai. Người thử nghiệm trên các điện thoại, phiên bản Android và mạng khác nhau sẽ đi đến những màn hình mà người xem xét đi đến, và phản hồi của họ cho bạn biết chỗ nào bị lỗi. Điều đó giúp bạn tìm và sửa lỗi; nó không thay đổi cách Google xem xét ứng dụng. Nếu bạn cần kiến thức cơ bản về chính kênh thử nghiệm, hãy xem thử nghiệm khép kín trên Google Play hoạt động như thế nào.

Nên sửa rồi gửi lại, hay kháng nghị?

Gửi lại bản phát hành đã sửa

Các bước gửi lại của Google không chỉ là tải lên một mã phiên bản mới:

1. Đọc chính sách được nêu trong email và thông báo của bạn, đồng thời kiểm tra ứng dụng theo cả các chính sách khác; Google cảnh báo rằng các vi phạm tiếp theo có thể dẫn đến các biện pháp thực thi tiếp theo.
2. Cập nhật mọi loại bản phát hành có chứa phiên bản bị ảnh hưởng, không chỉ kênh phát hành công khai: bao gồm cả kênh thử nghiệm công khai, khép kín và nội bộ.
3. Tải lên gói ứng dụng đã sửa và vô hiệu hóa các gói không tuân thủ. Google cảnh báo rằng nếu bạn không vô hiệu hóa chúng, lần gửi lại sẽ thất bại và các phiên bản đang phát hành có thể bị gỡ.
4. Trong mỗi kênh bị ảnh hưởng, chọn Manage track và Create new release, thêm gói đã sửa (hoặc hủy bản nháp đang chứa gói vi phạm), và đảm bảo phiên bản không tuân thủ được liệt kê trong mục Not included.
5. Lưu, chọn Review release, rồi triển khai.

Sau đó, thay đổi sẽ chờ được xử lý. Google cho biết: “Quá trình xử lý có thể mất vài giờ hoặc tối đa bảy ngày (hoặc lâu hơn trong trường hợp ngoại lệ)” (Kiểm soát thời điểm xem xét và phát hành thay đổi đối với ứng dụng).

Đã sửa, nhưng cảnh báo vẫn còn

Nếu phiên bản đã sửa đang được phát hành mà Policy status vẫn hiển thị vấn đề, hãy so sánh các mã phiên bản và kênh mà cảnh báo nêu tên với những gì hiện đang hoạt động: một gói không tuân thủ còn sót lại trên kênh thử nghiệm là điều đầu tiên cần loại trừ. Phiên bản mới hơn không tự động xóa mọi mục thực thi. Nếu mọi thứ đều khớp, hãy liên hệ bộ phận hỗ trợ Play Console kèm các mã phiên bản, các kênh bị ảnh hưởng và mọi mã tham chiếu yêu cầu hỗ trợ trước đó.

Kháng nghị quyết định

Google khôi phục ứng dụng khi họ đã mắc lỗi và nhận thấy ứng dụng không vi phạm chính sách. Để kháng nghị, hãy làm theo hướng dẫn trong email thực thi chính sách hoặc dùng biểu mẫu kháng nghị của Google. Bạn có thể gửi một kháng nghị cho mỗi biện pháp thực thi (Quản lý vi phạm chính sách và kháng nghị), và Google trả lời kháng nghị bằng tiếng Trung, tiếng Anh, tiếng Nhật và tiếng Hàn. Google không công bố thời gian phản hồi kháng nghị, và các báo cáo của nhà phát triển lẫn lộn giữa phản hồi kháng nghị với các lần xem xét bản phát hành sau đó, vì vậy hãy lên kế hoạch mà không dựa vào một ngày cụ thể.

Hãy viết kháng nghị như một bản trình bày bằng chứng, không phải lời than phiền: mã phiên bản đã được xem xét, thiết bị và phiên bản Android bạn đã thử, các bước chính xác, video quay màn hình luồng thao tác mà thông báo nêu tên, và những gì bạn đã thay đổi, nếu có.

Bị từ chối vì Broken Functionality có gây hại cho tài khoản hoặc thử nghiệm khép kín của bạn không?

Trang Quy trình thực thi của Google trình bày sự khác biệt:

• “Việc bị từ chối không ảnh hưởng đến tình trạng tài khoản nhà phát triển Google Play của bạn.”
• “Nếu một bản cập nhật cho ứng dụng hiện có bị từ chối, phiên bản ứng dụng đã phát hành trước bản cập nhật đó sẽ vẫn có sẵn trên Google Play.”
• “Việc tạm ngưng có thể xảy ra do vi phạm chính sách nghiêm trọng hoặc nhiều lần, cũng như do ứng dụng nhiều lần bị từ chối hoặc bị gỡ.”

Google không công bố số lần bị từ chối nào là an toàn. Gửi lại cùng một lỗi chính là kiểu hành vi mà dòng thứ ba mô tả.

Còn thử nghiệm khép kín 14 ngày thì sao?

Yêu cầu về thử nghiệm của Google đòi hỏi các tài khoản cá nhân được tạo sau ngày 13 tháng 11 năm 2023 phải có ít nhất 12 người thử nghiệm chọn tham gia liên tục trong ít nhất 14 ngày trước khi đăng ký quyền truy cập vào kênh phát hành công khai. Yêu cầu này không nói việc một bản phát hành trên kênh khép kín bị từ chối vì chính sách sẽ đặt lại, tạm dừng hay giữ nguyên khoảng thời gian đó, và các khẳng định trên diễn đàn theo bất kỳ hướng nào đều chỉ là phỏng đoán. Những gì bạn có thể kiểm tra: người thử nghiệm của bạn có còn một bản phát hành đã được phê duyệt trên kênh hay không, và trang tổng quan (Dashboard) hiển thị gì về quyền truy cập vào kênh phát hành công khai. Hãy giữ người thử nghiệm tiếp tục chọn tham gia trong lúc bạn sửa lỗi, và hỏi bộ phận hỗ trợ Play Console về trường hợp của bạn nếu Dashboard thay đổi. Bản thân quy định được giải thích trong 14 ngày liên tục nghĩa là gì.

Google có từ chối ứng dụng WebView hoặc TWA vì bị lỗi không?

Với ứng dụng dựa trên web, các bước kiểm tra Broken Functionality cũng giống như với mọi ứng dụng khác: trang web phải tải được bên trong ứng dụng ngay từ lần cài đặt sạch, trạng thái ngoại tuyến và trạng thái lỗi phải tự giải thích, và mọi liên kết đều phải dẫn đến đâu đó. Nếu ứng dụng phần lớn chỉ là một lớp hiển thị mỏng của trang web, phần Limited Functionality and Content mới là rủi ro lớn hơn. Việc chuyển từ TWA sang WebView, hoặc ngược lại, chưa từng được chứng minh là tự nó khắc phục được việc bị từ chối.

PrimeTestLab hỗ trợ thế nào trước lần xem xét tiếp theo?

PrimeTestLab cung cấp từ 12 tester thật trở lên trên thiết bị thật chạy từ Android 7 đến 17, chọn tham gia trọn 14 ngày, và bắt đầu thử nghiệm sau 4-6 giờ. Chúng tôi đã thực hiện thử nghiệm có quản lý cho 12.100+ ứng dụng với người thử nghiệm ở 120+ quốc gia.

Tự thử nghiệm hay thử nghiệm có quản lý

Nếu Google không cấp quyền truy cập vào kênh phát hành công khai sau khi bạn hoàn tất đầy đủ đợt thử nghiệm với PrimeTestLab, bạn chọn thử nghiệm lại miễn phí hoặc hoàn tiền toàn bộ; xem chính sách hoàn tiền và thử nghiệm lại miễn phí. Điều đó áp dụng cho yêu cầu về thử nghiệm, không áp dụng cho việc mã nguồn của bạn bị từ chối vì chính sách. Các gói bắt đầu từ $19.99 cộng 5% phí dịch vụ khi thanh toán (tối thiểu $1.50), và phí đăng ký một lần 25 USD của Google được tính riêng. So sánh các gói trên trang bảng giá.

Câu hỏi thường gặp

Tóm lại

Nếu bạn muốn người thật trên thiết bị thật tìm ra màn hình bị lỗi trước người xem xét tiếp theo, PrimeTestLab đảm nhận phần thử nghiệm khép kín trong lúc bạn sửa ứng dụng.