Ứng dụng phải hỗ trợ kích thước trang bộ nhớ 16 KB: cách khắc phục

Cảnh báo thì ngắn, cùng lắm chỉ nêu một tên tệp, và nó xuất hiện đúng lúc bạn tưởng bản dựng đã xong. Vì thế mà ba nước đi sai giống hệt nhau cứ lặp lại: nhà phát triển tin vào một hạn chót đã dời, nâng phiên bản framework rồi cho là xong việc, hoặc kiểm tra một tệp APK cục bộ mà chẳng bao giờ nhìn tới bundle mà Google thực sự dựng từ đó. Bài viết này được sắp xếp theo đúng cách vấn đề thực sự được giải quyết, tức là nhận diện, truy nguyên, sửa chữa rồi chứng minh, và mọi nội dung trong đây còn đúng tính đến ngày 5 tháng 8 năm 2026, đã đối chiếu với hướng dẫn kích thước trang của Google đúng vào ngày trang đó được cập nhật lần cuối. Ở những chỗ bằng chứng chỉ là trình theo dõi lỗi của người bảo trì chứ không phải ghi chú phát hành chính thức, trang này nói rõ điều đó ngay trên thẻ thay vì làm tròn thành sự thật.

Khắc phục trong ba bước

Bản thân yêu cầu này rất hẹp. Hướng dẫn kích thước trang của Google nói rằng ứng dụng nhắm tới Android 15 (cấp độ API 35) trở lên phải hỗ trợ kích thước trang bộ nhớ 16 KB trên thiết bị 64 bit, và kể từ ngày 1 tháng 2 năm 2027 bạn sẽ không phát hành được các bản cập nhật chưa đáp ứng. Nó chỉ áp dụng cho mã native. Nếu ứng dụng của bạn cùng mọi thư viện và SDK bên trong đều thuần Java hoặc Kotlin, Google khẳng định ứng dụng của bạn đã hỗ trợ thiết bị 16 KB. Rắc rối nằm ở chỗ phần lớn nhà phát triển thấy cảnh báo này đều tin mình thuộc nhóm đó, mà thực ra thì không.

Toàn bộ quyết định gói gọn trong một màn hình

Trước khi động vào bất kỳ số phiên bản phụ thuộc nào, hãy đi qua cây này. Nó tốn khoảng hai phút và là khác biệt giữa sửa đúng chỗ với nâng cấp mười một gói vốn chưa bao giờ là vấn đề.

Cảnh báo trong Play Console thực sự nghĩa là gì

Câu chữ rất quan trọng, vì phiên bản hoảng loạn của câu chuyện này lan nhanh hơn phiên bản chính xác. Hãy đọc đúng những dòng chữ Google thật sự hiển thị, và phạm vi trở nên hẹp lại và xử lý được.

Có hai cách hiểu thường sai về thẻ đó. Thứ nhất, "Action by Feb 1, 2027" không phải là đồng hồ đếm ngược tới lúc bị xóa; chính văn bản của Google trên cùng trang mô tả kết quả là bạn không phát hành được các bản cập nhật đó. Thứ hai, dòng Extension granted có xuất hiện trong ảnh chụp của Google, nhưng điều đó không xác lập rằng hiện có một quy trình xin gia hạn đang mở cho bạn. Chỉ coi việc gia hạn là có thật khi bạn nhìn thấy tùy chọn đó ngay trong Play Console của mình.

Bạn thực sự đã đọc hạn chót nào?

Có ba mốc đang lan truyền và chỉ một mốc còn hiệu lực. Hãy chọn mốc bạn từng thấy, công cụ này sẽ xác định trạng thái của nó so với trang Google hiện hành, vốn được cập nhật lần cuối vào ngày 5 tháng 8 năm 2026.

Yêu cầu 16 KB có ảnh hưởng tới ứng dụng của tôi không?

Ứng dụng thuần Java hoặc Kotlin

Google nói rất rõ ở điểm này: nếu ứng dụng của bạn cùng toàn bộ thư viện và SDK trong đó chỉ dùng Java hoặc Kotlin, ứng dụng của bạn đã hỗ trợ thiết bị 16 KB. Google vẫn khuyên nên thử trong môi trường 16 KB để bắt các lỗi thoái lui ngoài dự tính, và việc đó chỉ tốn của bạn một lượt chạy máy ảo.

Cái bẫy nằm ở cụm "cùng toàn bộ thư viện và SDK trong đó". Chỉ một phụ thuộc về cơ sở dữ liệu, phân tích, báo lỗi, media, bản đồ, học máy hay bảo mật cũng đủ thêm tệp nhị phân native vào một dự án mà mã nguồn của chính nó không có gì ngoài Kotlin. "Tôi không viết C++" không phải bằng chứng. Thư mục lib mới là bằng chứng.

Flutter, React Native, Unity, Kivy và các công cụ tạo ứng dụng không cần code

Các nền tảng này vốn dĩ đi kèm runtime native, tệp nhị phân của engine và thư viện plugin, nên gần như luôn nằm trong phạm vi. Google nêu đích danh các công cụ tạo ứng dụng bên thứ ba có dùng thư viện native như một cách khiến ứng dụng bị ảnh hưởng ngay cả khi tác giả chưa từng viết C hay C++. Thứ khác nhau không phải là bạn có mã native hay không mà là gói nào đã mang phần đang lỗi vào, và vì thế việc truy nguyên tên tệp phải đi trước mọi lần nâng cấp.

Cách kiểm tra, chính xác từng bước

Mở tệp APK phát hành, mở rộng lib, rồi nhìn các thư mục ABI bên trong, thường là arm64-v8a và x86_64. Có bất kỳ tệp shared object nào nghĩa là ứng dụng của bạn dùng mã native. Không có tệp .so và không có thư mục lib nghĩa là tệp APK này hoàn toàn không dùng mã native. Cột Alignment trong trình phân tích hiển thị thông báo cảnh báo cho những tệp có vấn đề căn chỉnh, và đó là con đường nhanh nhất từ "có gì đó sai" tới một cái tên tệp.

Vì sao tệp nhị phân 4 KB thất bại trên thiết bị 16 KB

Đó là toàn bộ cơ chế, và nó giải thích con số bạn sẽ gặp đi gặp lại. Căn chỉnh được biểu diễn dưới dạng lũy thừa của hai: 2**12 là 4096 byte, 2**14 là 16384 byte. Quy tắc của Google là mỗi phân đoạn LOAD trong một thư viện native phải căn chỉnh ở 2**14 trở lên. Thư viện dựng ở 2**14 chạy được trên cả thiết bị 4 KB lẫn 16 KB, vì 16384 là bội số chẵn của 4096. Thư viện dựng ở 2**12 chỉ chạy được với kích thước trang nhỏ hơn. Chính sự bất đối xứng đó là lý do cách sửa luôn là "nâng mức căn chỉnh lên" chứ không bao giờ là "phát hiện xem thiết bị nào".

Còn một ràng buộc thứ hai hoàn toàn tách biệt và nằm ngoài thư viện. Các thư viện native lưu ở dạng không nén bên trong tệp APK cũng phải nằm trên ranh giới 16 KB trong chính kho lưu trữ ZIP. Đó là thuộc tính của cách đóng gói, được kiểm tra bằng zipalign và do plugin dựng của bạn cấu hình, và nó có thể sai ngay cả khi từng thư viện bên trong đã căn chỉnh hoàn hảo. Giữ hai ý niệm đó tách bạch chính là điều hữu ích nhất bạn có thể mang theo từ mục này.

Cách sửa ngắn nhất cho từng framework

Toàn bộ các mốc trong một bảng

Các nhãn độ tin cậy mang cùng một ý nghĩa ở khắp trang này. ĐÃ KIỂM CHỨNG nghĩa là một nguồn gốc hiện hành nói thẳng điều đó. MỘT PHẦN nghĩa là một nguồn đáng tin đỡ được phần cốt lõi của khẳng định nhưng không đỡ được mọi chi tiết triển khai. ĐƯỢC BÁO CÁO nghĩa là bằng chứng nằm ở trình theo dõi lỗi của người bảo trì hoặc ở báo cáo của nhà phát triển chứ không phải ghi chú phát hành chính thức.

Tìm đúng thư viện đang gây ra lỗi

Bắt đầu từ APK Analyzer

Mở Build > Analyze APK..., nạp tệp APK phát hành, rồi mở rộng lib. Bên trong bạn sẽ thấy một thư mục cho mỗi ABI, thường là arm64-v8a và x86_64. Cột Alignment hiển thị thông báo cảnh báo với những tệp có vấn đề căn chỉnh. Cảnh báo của chính Android Studio và Lint cũng làm nổi bật các thư viện native chưa đạt yêu cầu, nên bạn có thể thấy cùng một phát hiện xuất hiện ở nhiều chỗ.

Hãy ghi lại mọi tên tệp bị gắn cờ trước khi động vào một số phiên bản nào. Kiểm tra riêng cả hai thư mục ABI: chuyện arm64-v8a đạt trong khi x86_64 trượt, hoặc ngược lại, là hoàn toàn bình thường, vì đó là hai tệp nhị phân khác nhau được dựng bởi những quy trình có thể khác nhau.

Giải mã kết quả từ dòng lệnh

Nếu bạn thích làm việc trong terminal, Google cung cấp check_elf_alignment.sh để báo ALIGNED hoặc UNALIGNED cho một tệp APK, và bạn có thể kiểm tra trực tiếp một thư viện bằng llvm-objdump. Cả hai đều cần Android SDK Build-Tools 35.0.0 trở lên. Hãy dán bất cứ thứ gì chúng in ra vào ô bên dưới và công cụ này sẽ đọc lại cho bạn.

Xác định phụ thuộc nào đang sở hữu nó

Play Console và APK Analyzer đều đưa cho bạn một tên tệp mà không nói ai là chủ. Hãy gõ tên đó vào bên dưới, công cụ này sẽ cho bạn biết những gì đã biết về tệp nhị phân ấy, kèm theo chất lượng bằng chứng, và đưa cho bạn các câu lệnh tìm kiếm đã điền sẵn tên tệp của bạn.

Kiểm tra app bundle, không chỉ tệp APK cục bộ

Đây là cơ chế đằng sau phiên bản khó chịu nhất của vấn đề: nhà phát triển nâng cấp mọi thứ, kiểm tra tệp APK cục bộ, thấy kết quả sạch, tải lên, và cảnh báo vẫn còn nguyên. Không có thứ nào họ kiểm tra là sai cả. Họ chỉ là chưa bao giờ kiểm tra đúng thứ mà Play đánh giá.

Vậy nên hãy chạy lệnh này trên chính bundle bạn sắp tải lên, lần nào cũng vậy:

bundletool dump config --bundle=app-release.aab | grep alignment

PAGE_ALIGNMENT_16K là kết quả bạn muốn. PAGE_ALIGNMENT_4K nghĩa là bundle đang bảo bundletool đóng gói thư viện native theo ranh giới 4 KB, nên mọi tệp APK Play dựng từ đó đều sẽ sai. Google cảnh báo cụ thể rằng Android Gradle Plugin 8.3 đến 8.5 có thể tạo ra đúng sự lệch pha này: bản dựng cục bộ trông đã căn chỉnh, còn ứng dụng mà Play dựng từ bundle lại không cài đặt đúng cách trên thiết bị 16 KB. Cách khắc phục được ưu tiên là chuyển lên Android Gradle Plugin 8.5.1 trở lên.

Mọi câu lệnh, với tên tệp của chính bạn trong đó

Gõ tên tệp của bạn một lần. Mọi câu lệnh bên dưới sẽ tự viết lại, và mỗi tab hiển thị đúng kết quả được tính là đạt, nên bạn không bao giờ phải đoán xem kết quả có tốt hay không.

AGP, NDK và cái bẫy đóng gói

Vùng giữa nguy hiểm là Android Gradle Plugin 8.3 đến 8.5. Trong khoảng đó, một bản dựng tại chỗ có thể trông hoàn toàn đúng trong khi bundletool không căn chỉnh ZIP cho các tệp APK mà nó tạo ra từ bundle của bạn để giao cho Play, và câu chữ của Google về hậu quả rất thẳng: ứng dụng dựng từ bundle đó sẽ không cài đặt đúng cách. Nếu bạn đang ở 8.5.0 và tệp APK cục bộ vượt qua mọi phép kiểm tra bạn nghĩ ra được, thì đây là thứ đầu tiên cần loại trừ.

Bảng tra thiết lập bản dựng

Phần mà việc đóng gói không sửa được

Nếu chính mã C hoặc C++ của bạn giả định một kích thước trang, không cờ dựng nào cứu bạn được. Hãy bỏ các giá trị 4096 viết cứng và mọi chỗ dựa vào hằng số PAGE_SIZE cố định, truy vấn giá trị thật lúc chạy bằng getpagesize() hoặc sysconf(_SC_PAGESIZE), rồi rà lại mọi lời gọi mmap() cùng mọi tham số mà bạn đang tự căn theo trang bằng tay. Đây là nhóm lỗi khiến ứng dụng cài đặt sạch sẽ trên thiết bị 16 KB, vượt qua các phép kiểm tra bundle, rồi sập ngay lần đầu chạm vào ánh xạ bộ nhớ.

Thử trên môi trường 16 KB thật

Bạn có ba lối đi thực dụng và hai lối chuyên biệt. Hãy chọn lối nào bạn thực sự với tới được ngay hôm nay; xét về mục đích bắt lỗi kích thước trang thì chúng không khác nhau về chất lượng.

adb shell getconf PAGE_SIZE

Thực sự nên chạy thử những gì

Khi môi trường đã được xác nhận, lượt thử có ích không phải là "ứng dụng có mở lên không". Lỗi native tụ lại ở những tính năng chạm tới mã native, nên hãy chủ động chạy chúng: khởi động nguội, di chuyển qua các màn hình, camera, đọc ghi cơ sở dữ liệu, phát và ghi media, đăng nhập, tác vụ nền, mọi tính năng học máy hay thực tế tăng cường, mọi bề mặt của plugin native, và mọi phần trong mã của chính bạn có dùng ánh xạ bộ nhớ. Nếu một tính năng chạy trên một trong các thư viện bạn vừa nâng cấp, thì chính tính năng đó là phép thử.

Vì sao cảnh báo sống sót qua một lần nâng cấp

Hai mục trong số đó xứng đáng có một lời dè dặt thay vì một câu trả lời chắc nịch. Không nguồn gốc nào xác lập Google Play mất bao lâu để xem xét lại một bundle đã tải lên, nên nếu cảnh báo của bạn còn nguyên ngay sau khi tải lên thì cách làm trung thực là xác nhận mã phiên bản mới đã xuất hiện ở mục bản phát hành và app bundle mới nhất rồi kiểm tra lại sau, thay vì tin vào một con số cụ thể nào đó bạn đọc được về thời gian xử lý. Và một ứng dụng chỉ chạy được nhờ chế độ tương thích can thiệp thì không phải đã được sửa, nó chỉ đang được châm chước.

Những thư viện bên thứ ba cứ xuất hiện lại

Hãy dùng phần này làm điểm khởi đầu khi một tên tệp trông quen thuộc, rồi đối chiếu với các bản phát hành hiện tại và issue đang mở của dự án đó. Ở đâu bằng chứng chỉ là trình theo dõi lỗi của người bảo trì chứ không phải ghi chú phát hành, thẻ sẽ ghi rõ điều đó.

Liên quan thế nào tới hạn chót API 36 ngày 31 tháng 8 năm 2026

Google Play yêu cầu ứng dụng mới và bản cập nhật ứng dụng phải nhắm tới Android 16 (cấp độ API 36) kể từ ngày 31 tháng 8 năm 2026, kèm khả năng xin gia hạn đến ngày 1 tháng 11 năm 2026. Đó là thay đổi ở tệp manifest và ở hành vi ứng dụng. Còn quy tắc 16 KB là thay đổi về tương thích nhị phân. Nhà phát triển nâng targetSdk vào thứ Hai rồi thấy cảnh báo 16 KB vào thứ Ba không hề làm hỏng thứ gì: các thư viện native vốn đã được dựng cho trang 4 KB, và cấp độ mục tiêu cao hơn chỉ đơn giản đưa ứng dụng vào phạm vi của một phép kiểm tra vốn dĩ sẽ áp dụng.

Trên thực tế, hãy xem chúng là một cuộc di chuyển duy nhất với hai bằng chứng. Đằng nào bạn cũng sẽ nâng cấp độ mục tiêu, vậy hãy xếp đợt rà soát thư viện native vào cùng bản phát hành thay vì phát hiện ra giữa lúc chạy nước rút cho API 36. Để xem đầy đủ các cấp độ theo loại thiết bị, các trường hợp ngoại lệ và cơ chế gia hạn của quy tắc API mục tiêu, hãy đọc bài viết của chúng tôi về hạn chót API 36 của Google Play, còn để xem toàn bộ trình tự từ tài khoản đến kênh phát hành công khai thì đọc bài viết về yêu cầu phát hành năm 2026.

Cổng phát hành trước khi tải lên

Tiến độ của bạn chỉ được lưu trong trình duyệt này. Không có gì được gửi đi đâu cả, và xóa dữ liệu trình duyệt sẽ xóa luôn tiến độ.

Chỗ này va chạm với thử nghiệm khép kín ra sao

Trình tự gây đau đớn thường diễn ra thế này. Một tài khoản nhà phát triển cá nhân bắt đầu thử nghiệm khép kín, khoảng thời gian 14 ngày duy trì tham gia liên tục bắt đầu chạy, rồi đâu đó giữa chừng một lần nâng cấp độ mục tiêu làm lộ ra cảnh báo 16 KB. Giờ nhà phát triển vừa dựng lại các phụ thuộc native vừa phải giữ cho nhóm tester quanh mình còn nguyên vẹn. Tải bản dựng mới lên kênh thử nghiệm thì không sao, và Google còn khuyến khích nhà phát triển tiếp tục cập nhật trong lúc thử nghiệm. Thứ làm hỏng cả đợt là phía tester im lặng.

Đó chính là phần PrimeTestLab giữ cho ổn định. Chúng tôi cung cấp 12 tester thật trên thiết bị thật trải từ Android 7 đến 17, đã chọn tham gia và được giữ đủ 14 ngày, để việc dựng lại của bạn diễn ra trên một đợt thử nghiệm ổn định thay vì một đợt đang sụp đổ. Thử nghiệm bắt đầu trong 4-6 giờ, và chúng tôi đã làm việc này cho hơn 7.400 ứng dụng tại 120+ quốc gia với tỷ lệ thành công 99,9%.

Tự tìm tester so với đợt thử nghiệm trọn gói

Nói thẳng về ranh giới: chúng tôi không dựng lại thư viện native cho bạn và bài viết này cũng không phải lời chào hàng cho việc đó. Phần việc 16 KB là của bạn, và toàn bộ nội dung phía trên được viết ra để phần việc đó ngắn nhất có thể. Thứ chúng tôi gỡ khỏi tay bạn là yêu cầu tester đang chạy song song, để hai vấn đề thôi giành nhau cùng hai tuần lễ.

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

Tóm lại