Google Play chặn APK (Blocking APK): Vì sao Play Console từ chối file APK và lộ trình bắt buộc AAB

Cụm từ "Google Play blocking APK" được gõ vào ô tìm kiếm bởi hai nhóm người hoàn toàn khác nhau, và đó là lý do phần lớn bài hướng dẫn trên mạng trả lời trật trọng tâm. Nhóm thứ nhất là nhà phát triển đang đứng trước Play Console và bị hệ thống từ chối file APK vừa tải lên. Nhóm thứ hai là người dùng hoặc tester đang cầm điện thoại, bấm cài file APK tải từ web và bị Android chặn lại bằng một hộp thoại đỏ. Hai tình huống này có nguyên nhân khác nhau, cách xử lý khác nhau và thuộc về hai hệ thống kiểm soát khác nhau của Google.

Bài viết này tách bạch cả hai tầng chặn, giải thích cơ chế kỹ thuật bên dưới, liệt kê những mã lỗi cụ thể bạn sẽ gặp, và quan trọng nhất là chỉ ra những trường hợp mà bạn KHÔNG cần làm gì cả vì app của bạn không nằm trong diện bị siết.

1. Hai tầng chặn APK hoàn toàn khác nhau của Google

Trước khi đi vào cách khắc phục, cần xác định chính xác bạn đang đứng ở tầng nào. Nhầm tầng là nguyên nhân khiến nhiều người mất cả buổi làm theo hướng dẫn không liên quan.

Tiêu chí	Tầng 1: Play Console chặn khi tải lên	Tầng 2: Thiết bị Android chặn khi cài đặt
Bạn đang ở đâu	Trình duyệt, màn hình Create new release trên Play Console	Điện thoại Android, màn hình cài đặt ứng dụng
Thông báo điển hình	"You uploaded an APK. You need to upload an Android App Bundle"	"Blocked by Play Protect", "App not installed", "This app was built for an older version of Android"
Hệ thống quyết định	Chính sách phát hành của Google Play (Publishing policy)	Google Play Protect, Package Manager của Android và lộ trình xác minh nhà phát triển
Ai bị ảnh hưởng	Nhà phát triển nộp app lên cửa hàng	Mọi người cài app từ nguồn ngoài cửa hàng (sideload)
Hướng xử lý	Chuyển sang build định dạng AAB	Ký app đúng chuẩn, nâng targetSdk, xác minh danh tính nhà phát triển

Phần 2 đến phần 6 dành cho tầng 1. Phần 7 đến phần 10 dành cho tầng 2. Bạn có thể nhảy thẳng tới phần tương ứng với tình huống của mình.

2. Vì sao Play Console không nhận file APK nữa?

Từ tháng 8 năm 2021, Google Play áp dụng quy định: mọi ứng dụng mới nộp lên cửa hàng bắt buộc phải ở định dạng AAB (Android App Bundle), đuôi file .aab. Định dạng APK truyền thống bị từ chối ngay tại bước tải lên, không có ngoại lệ với app mới.

Quyết định này không đến từ mong muốn siết chặt nhà phát triển mà đến từ một bài toán kỹ thuật thực tế. Một file APK duy nhất phải chứa tài nguyên cho mọi cấu hình thiết bị: thư viện native cho cả 4 kiến trúc CPU (armeabi-v7a, arm64-v8a, x86, x86_64), ảnh cho cả 6 mức mật độ điểm ảnh (ldpi tới xxxhdpi), chuỗi ngôn ngữ cho hàng chục thị trường. Người dùng cầm một chiếc điện thoại arm64 màn hình xxhdpi dùng tiếng Việt vẫn phải tải về toàn bộ phần dữ liệu dành cho x86, cho màn hình ldpi và cho tiếng Ả Rập.

Với AAB, bạn nộp lên một gói chứa toàn bộ tài nguyên chưa được đóng gói. Google Play mới là bên sinh ra các file APK cuối cùng, gọi là split APK, gồm base APK cộng với các configuration APK đúng khớp với thiết bị đang tải. Trung bình lượng dữ liệu tải về giảm khoảng 15 phần trăm so với APK universal, và với các app nặng tài nguyên đồ họa con số này có thể vượt 40 phần trăm. Nếu bạn quan tâm tới việc ép dung lượng xuống thấp hơn nữa, hãy đọc bài tối ưu dung lượng file AAB và APK giảm 50 phần trăm.

Một điểm quan trọng hay bị hiểu nhầm: APK không hề bị khai tử. Định dạng chạy trên thiết bị Android vẫn là APK. Chỉ có điều bây giờ Google Play là bên sinh ra file APK đó từ AAB của bạn, thay vì bạn tự sinh ra và nộp lên.

3. App cũ đang dùng APK có bị buộc chuyển sang AAB không?

Đây là câu hỏi khiến nhiều nhà phát triển hoảng loạn không cần thiết. Câu trả lời phụ thuộc vào thời điểm app được tạo trên Play Console:

• App tạo mới sau tháng 8 năm 2021: bắt buộc AAB ngay từ bản build đầu tiên. Không có đường lùi.
• App đã tồn tại trên Play trước mốc đó: vẫn được phép cập nhật bằng APK trong các bản release thông thường. Tuy nhiên Play Console liên tục hiển thị cảnh báo khuyến nghị chuyển đổi, và một số tính năng mới chỉ hoạt động với AAB.
• App dùng expansion file (OBB): cơ chế OBB đã ngừng nhận app mới, thay bằng Play Asset Delivery và Play Feature Delivery, và cả hai cơ chế này chỉ chạy được trên AAB.
• App Wear OS, Android TV, Automotive và Instant App: yêu cầu AAB nghiêm ngặt hơn app điện thoại thông thường.

Lời khuyên thực tế: dù bạn thuộc nhóm được miễn trừ, hãy chủ động chuyển sang AAB. Chi phí chuyển đổi thường chỉ là đổi một dòng lệnh build, còn cái giá của việc trì hoãn là bạn tự loại mình khỏi mọi tính năng phân phối mới của Google Play.

4. Bảng đối chiếu APK và AAB trên các tiêu chí thực dụng

Tiêu chí	APK (universal)	AAB (Android App Bundle)
Nộp lên Google Play cho app mới	Bị từ chối	Bắt buộc
Cài trực tiếp lên điện thoại	Cài thẳng được	Không cài thẳng được, phải qua bundletool
Giới hạn dung lượng tải về	Khoảng 100 MB cho file gốc, phần dư phải đưa vào expansion file	Khoảng 200 MB cho base cộng configuration APK, phần dư đưa vào asset pack
Ai giữ khóa ký bản phát hành	Bạn tự giữ, mất khóa là mất app	Google giữ qua Play App Signing, bạn chỉ giữ upload key có thể xin cấp lại
Tối ưu theo thiết bị	Không, mọi máy tải cùng một file	Có, mỗi máy chỉ tải phần tài nguyên nó cần
Hỗ trợ Play Feature Delivery (tải module theo yêu cầu)	Không	Có
Phù hợp để gửi cho khách hàng xem thử	Rất phù hợp	Không phù hợp, phải chuyển đổi trước
Phân phối ngoài Google Play (web, cửa hàng khác)	Dùng được	Phải chuyển sang APK trước

5. Danh sách mã lỗi upload thường gặp và cách sửa từng lỗi

Không phải mọi lỗi tải lên đều liên quan tới chuyện APK hay AAB. Dưới đây là những thông báo hay bị nhầm lẫn với nhau nhất:

5.1. "You uploaded an APK. You need to upload an Android App Bundle"

Đúng nghĩa đen: bạn đang kéo nhầm file .apk. Trong Android Studio, chọn Build → Generate Signed Bundle / APK rồi chọn nhánh Android App Bundle, không phải nhánh APK. Với dự án chạy Gradle từ dòng lệnh, dùng ./gradlew bundleRelease thay cho ./gradlew assembleRelease. File kết quả nằm ở app/build/outputs/bundle/release/app-release.aab.

5.2. "You uploaded an APK or Android App Bundle that is not signed with the upload certificate"

File của bạn đúng định dạng nhưng ký bằng sai keystore. Kiểm tra dấu vân tay chứng thư đang dùng bằng lệnh:

keytool -list -v -keystore my-upload-key.jks -alias my-alias

Rồi so sánh chuỗi SHA-256 với chuỗi hiển thị tại Play Console → Test and release → Setup → App signing. Nếu bạn thật sự làm mất upload key, Google cho phép xin cấp lại, còn nếu bạn làm mất app signing key mà chưa bật Play App Signing thì app coi như không thể cập nhật được nữa. Cách tạo và bảo quản keystore đúng chuẩn được trình bày trong bài tạo file AAB và Keystore ký app Android.

5.3. "You uploaded a debuggable APK or Android App Bundle"

Bạn đang nộp bản build debug. Kiểm tra khối buildTypes trong build.gradle, đảm bảo debuggable false ở biến thể release, và chắc chắn rằng bạn chọn đúng biến thể release khi build.

5.4. "Your app currently targets API level X and must target at least API level Y"

Google áp lộ trình target API level bắt buộc, cập nhật mỗi năm và thường siết vào cuối tháng 8. Nguyên tắc chung: bản phát hành mới phải nhắm tới phiên bản Android ra mắt trong vòng khoảng một năm trở lại. Sửa bằng cách nâng targetSdkVersion trong build.gradle, sau đó kiểm thử lại toàn bộ luồng xin quyền, vì mỗi lần nâng target API thường kéo theo thay đổi về quyền nền, quyền thông báo hoặc quyền truy cập bộ nhớ.

5.5. "Version code X has already been used"

Không liên quan tới định dạng, chỉ là bạn quên tăng versionCode. Mỗi bản tải lên phải có versionCode lớn hơn mọi bản đã từng tồn tại trên mọi kênh, kể cả bản đã bị xóa khỏi kênh thử nghiệm.

5.6. "This release is not compliant with the Google Play 64-bit requirement"

App có thư viện native nhưng thiếu bản dựng cho arm64-v8a. Bổ sung arm64-v8a vào cấu hình abiFilters hoặc ndk.abiFilters. Lỗi này rất hay xuất hiện ở các app game engine cũ hoặc app dùng thư viện xử lý ảnh và âm thanh biên dịch sẵn.

6. Play App Signing: điều thay đổi lớn nhất khi chuyển sang AAB

Khi nộp AAB, bạn buộc phải bật Play App Signing. Cơ chế này chia khóa ký thành hai lớp mà nhiều người mới thường nhầm lẫn:

• Upload key: khóa bạn dùng để ký file AAB trước khi tải lên. Google chỉ dùng khóa này để xác thực rằng đúng bạn là người nộp bản build. Nếu mất, bạn liên hệ Google để đăng ký khóa mới.
• App signing key: khóa Google dùng để ký các file APK cuối cùng gửi tới thiết bị người dùng. Google giữ khóa này trong hạ tầng bảo mật của họ. Bạn không bao giờ chạm tới, và cũng không bao giờ làm mất được.

Hệ quả thực tế cần nhớ: dấu vân tay SHA-1 và SHA-256 mà bạn khai báo cho Firebase, Google Sign-In, Google Maps SDK hay bất kỳ dịch vụ nào cần chứng thư phải là dấu vân tay của app signing key lấy từ Play Console, không phải của upload key trên máy bạn. Đây là nguyên nhân số một khiến chức năng đăng nhập Google chạy ngon trên bản debug nhưng chết ngay khi tải bản từ cửa hàng về.

7. Tầng 2: vì sao điện thoại Android chặn file APK khi cài đặt?

Sang tình huống thứ hai. Bạn gửi file APK cho tester, họ tải về và bị chặn. Có bốn cơ chế khác nhau có thể là thủ phạm, và thông báo lỗi tuy giống nhau nhưng nguyên nhân thì khác hẳn.

7.1. Google Play Protect quét và gắn cờ

Play Protect chạy sẵn trên gần như mọi thiết bị Android có dịch vụ Google. Nó quét file APK trước khi cài và hiển thị "Blocked by Play Protect" nếu thấy dấu hiệu đáng ngờ: chữ ký lạ chưa từng gặp, app xin tổ hợp quyền nhạy cảm, hoặc file khớp với mẫu mã độc đã biết. Đây là chủ đề riêng, được xử lý chi tiết trong bài Unsafe App Blocked: sửa lỗi app bị Google Play Protect chặn cài đặt.

7.2. Chặn app nhắm tới API level quá cũ

Từ Android 14, hệ điều hành từ chối cài đặt các ứng dụng có targetSdkVersion thấp hơn 23. Thông báo hiện ra thường là "This app was built for an older version of Android and doesn't include the latest privacy protections". Lý do là các app target quá cũ được hưởng cơ chế xin quyền kiểu cũ, cấp toàn bộ quyền ngay lúc cài, và mã độc lợi dụng chính lỗ hổng này. Cách sửa duy nhất là nâng targetSdk rồi build lại.

7.3. Xung đột chữ ký với bản đã cài

Nếu máy đang có sẵn một app cùng applicationId nhưng ký bằng khóa khác, Package Manager sẽ báo "App not installed" hoặc "Package conflicts with an existing package". Tình huống kinh điển: tester đã cài bản từ Google Play (ký bằng app signing key của Google), giờ bạn gửi bản APK ký bằng keystore của bạn. Hai chữ ký khác nhau nên hệ thống từ chối ghi đè. Cách xử lý: gỡ hẳn bản cũ trước khi cài, hoặc dùng Internal App Sharing thay vì gửi file thô.

7.4. Cài đặt từ nguồn không xác định bị khóa

Từ Android 8 trở đi, quyền cài app từ nguồn ngoài được cấp riêng cho từng ứng dụng nguồn chứ không còn là một công tắc chung toàn máy. Nghĩa là tester phải vào Cài đặt → Ứng dụng → Quyền đặc biệt → Cài đặt ứng dụng không xác định và bật riêng cho trình duyệt hoặc ứng dụng quản lý file mà họ dùng để mở APK.

8. Lộ trình xác minh nhà phát triển với app cài ngoài Google Play

Đây là thay đổi lớn nhất của hệ sinh thái Android trong nhiều năm và cũng là lý do lượng tìm kiếm cụm "Google Play blocking APK" tăng mạnh gần đây.

Google đã công bố lộ trình yêu cầu mọi ứng dụng cài đặt trên thiết bị Android được chứng nhận (certified Android device) đều phải đến từ nhà phát triển đã xác minh danh tính, kể cả khi ứng dụng đó được cài từ bên ngoài Google Play. Điểm cần hiểu cho đúng:

• Yêu cầu này nhắm vào danh tính của người phát hành, không phải vào nội dung app. Google không duyệt nội dung app sideload, chỉ xác nhận rằng đằng sau file APK đó có một danh tính thật chịu trách nhiệm.
• Nhà phát triển phân phối ngoài Google Play sẽ đăng ký qua một console riêng, khai báo tên hợp pháp, thông tin liên hệ và danh sách package name cùng khóa ký mà mình sở hữu.
• Lộ trình triển khai theo từng nhóm quốc gia trước rồi mới mở rộng toàn cầu, trải qua vài năm chứ không bật một lần.
• Thiết bị không được chứng nhận, tức không cài dịch vụ Google, không nằm trong phạm vi áp dụng.
• Các luồng dành riêng cho lập trình viên như cài qua adb install và các kênh dành cho học tập, nghiên cứu vẫn được giữ đường riêng.

Hệ quả thực tế với nhà phát triển Việt Nam: nếu bạn đang phát hành app qua Google Play thì bạn đã xác minh danh tính rồi, xem bài xác minh danh tính tài khoản Google Play Developer, và bạn gần như không phải làm gì thêm. Nếu bạn đang có mô hình phát hành file APK trực tiếp từ website công ty cho khách hàng nội bộ, hãy bắt đầu chuẩn bị hồ sơ pháp nhân từ bây giờ thay vì đợi tới lúc bị chặn.

9. Khi nào bạn KHÔNG cần lo về việc Google chặn APK

Phần này quan trọng không kém phần hướng dẫn sửa lỗi, vì rất nhiều người đang bỏ công sức vào việc mình không cần làm:

• Bạn chỉ build APK để chạy thử trên máy mình hoặc trên trình giả lập: hoàn toàn bình thường, không có quy định nào cấm.
• Bạn dùng APK trong CI để chạy kiểm thử tự động: quy trình test không đi qua Play Console nên không bị ảnh hưởng.
• Bạn phân phối app nội bộ doanh nghiệp qua Managed Google Play hoặc MDM: đây là kênh riêng, có cơ chế quản trị riêng.
• App của bạn phát hành trước tháng 8 năm 2021 và bạn chỉ cập nhật vá lỗi nhỏ: bạn vẫn còn đường APK, dù nên chuyển đổi sớm.
• Bạn gửi bản thử cho tester qua kênh Internal Testing: tester tải app từ Google Play chứ không cài file thô, nên không dính bất kỳ tầng chặn nào. Đọc thêm về phân biệt Internal Testing và Closed Testing.

10. Ba cách gửi bản thử cho tester mà không đụng tới file APK thô

Cách làm	Ưu điểm	Hạn chế
Internal App Sharing (Play Console)	Tải thẳng file AAB hoặc APK lên, nhận về một đường link cài đặt, không cần tăng versionCode, không cần qua kiểm duyệt	Người nhận phải bật chế độ Internal app sharing trong ứng dụng Play Store
Internal Testing (tối đa 100 tester)	Tester cài qua Play Store như app thật, có đủ luồng cập nhật và thanh toán thử	Cần thêm email tester vào danh sách trước
Firebase App Distribution	Quản lý nhóm tester linh hoạt, tích hợp thẳng vào pipeline CI	Tester nhận file APK nên vẫn có thể vướng cảnh báo Play Protect trên một số máy

Với mọi dự án có kế hoạch lên Production, Internal App Sharing là lựa chọn ít ma sát nhất. Nó giúp bạn kiểm tra chính xác file APK mà Google sinh ra từ AAB, thay vì kiểm tra một bản universal APK khác với bản người dùng thật sự nhận được.

11. Quy trình 6 bước chuyển dự án từ APK sang AAB an toàn

1. Sao lưu keystore hiện tại ra ít nhất hai nơi lưu trữ tách biệt, kèm mật khẩu keystore và mật khẩu alias. Đây là bước không được phép bỏ qua.
2. Bật Play App Signing tại Play Console, mục Test and release → Setup → App signing. Với app cũ, bạn sẽ được hướng dẫn tải khóa ký hiện tại lên bằng công cụ PEPK.
3. Đổi lệnh build từ assembleRelease sang bundleRelease, hoặc đổi lựa chọn trong hộp thoại Generate Signed Bundle của Android Studio.
4. Kiểm tra kích thước tải về thực tế tại tab App bundle explorer trên Play Console. Con số hiển thị ở đây là dung lượng người dùng thật sự tải, khác với dung lượng file AAB bạn vừa nộp.
5. Cập nhật lại dấu vân tay SHA cho Firebase, Google Sign-In, Google Maps và mọi dịch vụ khác, lấy từ mục App signing chứ không lấy từ keystore trên máy.
6. Phát hành từ từ bằng Staged Rollout thay vì bung 100 phần trăm ngay. Xem bài Staged Rollout trên Google Play để biết cách chọn tỷ lệ và mốc theo dõi chỉ số crash.

12. Bốn sai lầm phổ biến khi xử lý lỗi chặn APK

• Đổi tên đuôi file từ .aab thành .apk: vô nghĩa, vì cấu trúc bên trong hai định dạng hoàn toàn khác nhau. Hệ thống đọc nội dung file chứ không đọc phần mở rộng.
• Tắt Play Protect trên máy tester rồi coi như đã xong: chỉ giấu triệu chứng trên đúng một chiếc máy. Người dùng thật vẫn thấy cảnh báo đỏ.
• Tạo keystore mới khi gặp lỗi sai chứng thư: đây là hành động phá hoại. Keystore mới đồng nghĩa app không thể cập nhật lên bản cũ nữa. Luôn tìm lại keystore gốc trước.
• Đưa file APK lên website công ty rồi quảng bá như kênh tải chính: vừa vướng lộ trình xác minh nhà phát triển, vừa mất toàn bộ tín hiệu xếp hạng trên cửa hàng. Đọc thêm về ASO và cách tối ưu lượt tải tự nhiên trên CH Play.

Kết luận

Câu chuyện "Google Play chặn APK" thực chất là hai câu chuyện. Ở phía nộp app, APK bị thay bằng AAB vì lý do tối ưu dung lượng phân phối, và việc chuyển đổi thường chỉ tốn một buổi làm việc nếu bạn giữ đúng keystore. Ở phía cài đặt, Android ngày càng siết chặt các file APK trôi nổi bên ngoài cửa hàng, và xu hướng này sẽ còn tiếp diễn cùng lộ trình xác minh danh tính nhà phát triển.

Nếu bạn đang mắc kẹt ở khâu đưa app lên Production sau khi đã build được AAB, dịch vụ 12 Tester thật của Uwmee Software hỗ trợ chạy trọn đợt Closed Testing 14 ngày kèm rà soát toàn bộ hồ sơ chính sách trước khi nộp đơn. Bước tiếp theo nên đọc là top 8 lỗi thường gặp khi up app lên Google Play và cách cài file AAB lên điện thoại bằng bundletool.