Hạn chót cấp API mục tiêu 36 của Google Play: điều gì thay đổi vào ngày 31 tháng 8 năm 2026

Điều gì thay đổi vào ngày 1 tháng 11 năm 2026

Ngày 1 tháng 11 năm 2026 khép lại giai đoạn gia hạn cấp API mục tiêu mà Google đã công bố. Nó không chấm dứt khả năng bạn nộp một bản cập nhật đạt chuẩn, và cũng không thay đổi những gì một ứng dụng đã phát hành mà không đổi gì cần có. Hai tình huống sau thường xuyên bị nhầm lẫn:

Trung tâm trợ giúp Google Play Console về yêu cầu cấp API mục tiêu, và hướng dẫn target SDK trên developer.android.com, cả hai đều được đọc vào ngày 15 tháng 10 năm 2026.

Mỗi năm Google nâng sàn cấp API mục tiêu của Play Store một lần, và 2026 là chu kỳ của API 36. Con số không phải chỗ rối. Chỗ rối là "yêu cầu về cấp API mục tiêu" thực ra là hai quy định đội chung một cái tên: một quy định chi phối những gì bạn được phép tải lên, còn một quy định khác, thấp hơn, chi phối ai còn có thể cài đặt thứ đã phát hành. Gần như mọi trang xếp hạng cho câu hỏi này đều làm nhoè hai thứ ấy, và đó là cách nhà phát triển kết thúc bằng việc dựng lại một ứng dụng lẽ ra không cần dựng lại, hoặc bỏ qua một cảnh báo trong Play Console vốn thực sự quan trọng.

Bài này tách chúng ra, đưa cho bạn các con số theo từng loại thiết bị, rồi trả lời câu mà hộp thư hỗ trợ của chúng tôi thực sự nhận được: chuyện này ảnh hưởng thế nào tới một ứng dụng đang đi được nửa kỳ thử nghiệm khép kín 12 người thử nghiệm trong 14 ngày liên tục? PrimeTestLab lo phần thử nghiệm đó cho nhà phát triển, nên chúng tôi thấy va chạm về thời điểm này liên tục, và hướng dẫn trong mục ấy đúng cho cả khi bạn dùng dịch vụ lẫn khi bạn tự tìm người thử nghiệm. Mọi mốc ngày và cấp API bên dưới đều đã được đối chiếu với chính các trang của Google vào ngày 9 tháng 8 năm 2026 và kiểm tra lại vào ngày 15 tháng 10 năm 2026, và những gì Google chưa thực sự ghi nhận thì được gắn nhãn thay vì lấp bằng một phỏng đoán tự tin.

Quy định gói trong một câu

Kể từ ngày 31 tháng 8 năm 2026, một ứng dụng thông thường cho điện thoại, máy tính bảng, máy gập hoặc Android Auto đã phải nhắm tới Android 16, cấp API 36 trở lên mới nộp được lên Google Play, dù đó là ứng dụng hoàn toàn mới hay bản cập nhật cho ứng dụng đã phát hành. Một câu đó bao trọn phần lớn người đọc. Các ngoại lệ, và cái sàn thấp hơn dành riêng cho ứng dụng bạn không đụng tới, là phần còn lại của bài này.

Một cái tên, hai quy định khác nhau

Google dùng cụm "yêu cầu về cấp API mục tiêu" cho hai thứ hành xử chẳng giống nhau chút nào. Tách chúng ra là điều giá trị nhất bạn có thể làm với trang này.

Vậy nên một ứng dụng nằm yên ở API 35 mà không có kế hoạch cập nhật thì vào ngày 31 tháng 8 vẫn đạt theo quy định 2, và trở thành không đạt ngay giây phút bạn thử phát hành bất cứ thứ gì theo quy định 1. Đó không phải mâu thuẫn mà là thiết kế: Google nâng chuẩn cho thứ được vào cửa hàng nhanh hơn nâng chuẩn cho thứ được ở lại trong đó.

Ba khái niệm Google định nghĩa chính xác

Chính sách dựa vào ba thuật ngữ, và mỗi thuật ngữ có một nghĩa cụ thể quyết định bạn thuộc quy định nào:

• Ứng dụng mới: ứng dụng "chưa được phát hành trên Google Play". Lần tải lên đầu tiên của một tên gói.
• Ứng dụng hiện có: ứng dụng đã được phát hành trên Google Play.
• Bản cập nhật: một phiên bản mới của ứng dụng hiện có, nộp để xem xét nhằm thay thế bản đang chạy. Bản cập nhật được xét theo quy định khi nộp, không phải theo quy định về khả dụng.

Yêu cầu theo loại thiết bị

"Ứng dụng Android" không phải một dòng duy nhất. Điện thoại, máy tính bảng, máy gập và Android Auto lên API 36. Wear OS và Android Automotive OS dừng ở API 35. Android TV và Android XR dừng ở API 34. Sàn dành cho ứng dụng bạn không cập nhật còn thấp hơn nữa, và nút chuyển bên dưới đổi qua lại giữa hai bộ số.

Android Auto không phải Android Automotive OS

Hai cái tên này mỗi năm lại làm nhà phát triển mất thời gian thật. Android Auto chiếu ứng dụng từ điện thoại lên màn hình xe, nên ứng dụng đó là ứng dụng điện thoại và theo quy định của điện thoại: API 36. Android Automotive OS là hệ điều hành chạy trên chính chiếc xe, và nó là một trong các ngoại lệ có cấp mục tiêu thấp hơn được nêu tên: API 35. Nếu bạn dựng ứng dụng nghe nhìn hoặc dẫn đường phát hành cho cả hai, bạn cần lấy mức cao hơn trong hai mức.

Điều này có áp cho bạn không? Trả lời ba câu hỏi

Quy định về API mục tiêu có phải là vấn đề của bạn ngay lúc này hay không phụ thuộc vào ba thứ: bạn sắp làm gì, bạn phát hành cho loại thiết bị nào, và bản dựng hiện tại của bạn thật sự nhắm tới đâu. Công cụ bên dưới áp các sàn đã công bố của Google lên đúng tổ hợp đó và cho bạn biết bạn đang thuộc quy định nào trong hai quy định.

Nếu kết luận nói bạn ổn, bạn vẫn nên xem danh sách kiểm tra trước hạn ở cuối bài, bởi "mã nguồn của tôi đặt target 36" và "tệp mà Google đánh giá có khai 36" không phải cùng một khẳng định. Cảm giác an toàn giả phổ biến nhất trong cả chu kỳ này là một nhà phát triển đọc tệp Gradle của mình thay vì đọc bundle đã tải lên.

Chuyện gì thực sự xảy ra nếu bạn lỡ ngày 31 tháng 8

Hai chuyện khác nhau, tuỳ bạn thuộc quy định nào. Nếu bạn thử tải lên một bản dựng dưới sàn, bản nộp đó không đạt yêu cầu. Nếu bạn chỉ để yên một ứng dụng đã phát hành đang nằm dưới sàn khả dụng, nó sẽ không còn tìm thấy được và cài được với người dùng mới trên máy chạy phiên bản Android cao hơn cấp mục tiêu của nó. Cả hai kết cục đều không phải là xoá ứng dụng.

Nếu bạn thử tải lên

Hãy để ý hậu quả này gắn với cái gì: với hành động tải lên. Chỉ riêng tờ lịch thì không làm gì được một bản dựng đang chạy. Đó là lý do một ứng dụng có thể hoàn toàn đạt chuẩn vào ngày 1 tháng 9 và bị chặn vào ngày 2 tháng 9, thuần tuý vì bạn quyết định tung một bản sửa lỗi.

Nếu bạn để một ứng dụng đã phát hành nằm dưới sàn

Đây là tình huống mà các đối thủ mô tả thành "ứng dụng của bạn biến mất", và cách nói đó sai theo hướng đáng kể. Chữ của Google là ứng dụng sẽ "stop being discoverable" với một nhóm người dùng cụ thể. Cụ thể là:

• Người dùng mới trên máy mới hơn mất quyền truy cập. Nếu máy của một người dùng chạy phiên bản Android cao hơn cấp mục tiêu của ứng dụng, Google Play không còn hiển thị hay cài ứng dụng cho họ nữa.
• Người dùng mới trên máy cũ hơn không bị ảnh hưởng. Máy chạy cấp API bằng hoặc thấp hơn cấp mục tiêu của ứng dụng vẫn nhận được nó.
• Ai đã cài trước không bị ảnh hưởng. Bất kỳ ai đã cài ứng dụng vẫn tìm thấy, cài lại và dùng được trên các phiên bản Android được hỗ trợ.
• Liên kết sâu nói đúng sự thật. Người dùng trên máy mới hơn không đủ điều kiện khi mở liên kết Play Store của bạn sẽ được báo rằng ứng dụng "made for an older version of Android".

Những gì không xảy ra

Tháng 8 nào chính sách này cũng sinh ra đúng bốn nỗi sợ trên diễn đàn hỗ trợ của Google. Không nỗi sợ nào là điều trang về cấp API mục tiêu mô tả.

Nhắm tới API 36 có cắt mất hỗ trợ cho máy cũ không?

Không, tự nó thì không. targetSdk khai báo cấp hành vi Android mà ứng dụng của bạn được dựng và kiểm thử cho nó. minSdk quyết định phiên bản Android cũ nhất mà ứng dụng cài được lên. Đó là hai con số riêng biệt, và nâng cấp mục tiêu lên 36 tự nó không nâng mức tối thiểu: ứng dụng của bạn vẫn hỗ trợ được các phiên bản Android cũ hơn xuống tới mức tối thiểu đó, miễn là mã của bạn và các dependency đã nâng vẫn tương thích.

Đây là hiểu lầm gây hoảng nhất mỗi chu kỳ. Một nhà phát triển đọc "phải nhắm tới Android 16", cho rằng nó nghĩa là "chỉ chạy trên Android 16", rồi kết luận Google vừa xoá sổ phần lớn số thiết bị mình với tới được. Hãy kéo mức tối thiểu bên dưới và xem thực sự có gì đổi.

Ba con số, và con số nào Google Play kiểm

Điều này nghĩa là gì nếu ứng dụng của bạn đang thử nghiệm khép kín

Nếu bạn là tài khoản nhà phát triển cá nhân mới đang chạy kỳ thử nghiệm khép kín bắt buộc với 12 người thử nghiệm trong 14 ngày liên tục, việc chuyển đổi, hoặc thời điểm gia hạn kết thúc, có thể rơi vào giữa cửa sổ của bạn. Nước đi an toàn là đưa bản dựng API 36 vào đúng kênh khép kín đó ngay bây giờ, giữ mọi người thử nghiệm tiếp tục tham gia, và đừng bao giờ để một hạn chót ép bạn đổi kênh hay bắt đầu lại với người thử nghiệm mới.

Trang của Google về cấp API mục tiêu và trang của Google về thử nghiệm khép kín do các nhóm khác nhau viết cho các mục đích khác nhau, và không trang nào nói về trang kia. Điều đó để lại một khoảng trống thật, và cách trung thực là chỉ cho bạn thấy chính xác chỗ mặt đất được ghi nhận kết thúc.

Những gì đã kiểm chứng

• Một tài khoản cá nhân mới thuộc diện áp dụng "phải chạy một thử nghiệm khép kín" với ít nhất 12 người thử nghiệm duy trì tham gia liên tục trong 14 ngày qua trước khi có thể đăng ký quyền truy cập vào kênh phát hành công khai. Điều này áp cho các tài khoản cá nhân tạo sau ngày 13 tháng 11 năm 2023. Đã kiểm chứng
• Tài liệu dành cho nhà phát triển của Google nói tệp APK tải lên phải đạt yêu cầu về cấp API mục tiêu của Play, và không công bố ngoại lệ nào cho các kênh thử nghiệm. Câu chữ đó trung lập với kênh chứ không riêng cho thử nghiệm, nên hãy lên kế hoạch rằng một bản tải lên mới vào kênh khép kín sau hạn chót sẽ cần API 36: đây là suy luận mạnh, không phải một quy định về kênh thử nghiệm đã được ghi nhận. Một phần
• Chính hướng dẫn của Google khuyến khích nhà phát triển tiếp tục cập nhật ứng dụng trong lúc thử nghiệm khép kín để sửa lỗi, và định nghĩa kỳ hợp lệ quanh tính liên tục của việc người thử nghiệm tham gia, chứ không quanh một tệp bị đóng băng. Đã kiểm chứng
• Thử nghiệm nội bộ giới hạn ở 100 người thử nghiệm và không thay thế được kỳ thử nghiệm khép kín hợp lệ. Đã kiểm chứng

Những gì Google chưa ghi nhận

Vì câu trả lời chưa biết, chiến lược đúng không phải là đoán nó. Mà là làm cho câu hỏi trở nên vô nghĩa bằng cách có sẵn một bản dựng đạt chuẩn trong kênh ngay bây giờ. Cách này an toàn dưới cả hai kết cục và chẳng tốn gì của bạn nếu tệp cũ vốn dĩ vẫn chạy tiếp.

Trình tự an toàn dù kết cục thế nào

1. Giữ nguyên kênh khép kín và nhóm người thử nghiệm đang có

   Đừng tạo kênh mới để chứa bản dựng API 36 và đừng gỡ người thử nghiệm đang tham gia. Tính liên tục 14 ngày mà Google đếm là chuyện người thử nghiệm ở lại tham gia, nên chính danh sách tham gia mới là tài sản bạn đang bảo vệ.

2. Hãy coi việc chuyển sang API 36 là một đầu việc riêng, với vòng kiểm thử riêng

   Hãy chạy các bước kiểm tra Android 16 trước khi tải lên, chứ không phải sau khi bị từ chối. Phát hiện layout edge-to-edge bị vỡ đúng vào ngày bạn cần phát hành là một ngày rất khác so với phát hiện nó sớm hơn một tuần.

3. Tải nó lên kênh khép kín hiện có với mã phiên bản cao hơn

   Mọi bundle thay thế đều cần mã phiên bản tăng lên. Google định nghĩa kỳ hợp lệ quanh tính liên tục của việc người thử nghiệm tham gia và khuyến khích rõ ràng việc tiếp tục sửa lỗi trong lúc thử nghiệm, nhưng không công bố một bảo đảm tuyệt đối bao trùm mọi tình huống thay bản dựng. Hãy giữ nguyên kênh và nguyên nhóm người thử nghiệm đang tham gia, rồi kiểm tra lại bộ đếm trong Play Console sau đó. Toàn bộ cơ chế của việc cập nhật giữa kỳ thử nghiệm rất đáng đọc nếu đây là chu kỳ đầu tiên của bạn.

4. Xác nhận bản phát hành thực sự đã tới người thử nghiệm

   Một bản phát hành đã xuất bản không đồng nghĩa với một bản đã giao tới nơi. Hãy kiểm tra rằng bản khép kín đang chạy, mã phiên bản cao hơn, và người thử nghiệm trong danh sách tham gia nhìn thấy bản cập nhật.

5. Kiểm tra lại trạng thái chính sách sau khi xử lý xong

   Hãy cho bundle thời gian để xử lý, rồi mở lại trang trạng thái chính sách của ứng dụng. Nếu cảnh báo về cấp API mục tiêu vẫn còn, hãy đi theo danh sách phân loại thay vì xoá bừa các bản phát hành.

6. Chỉ xin gia hạn nếu việc chuyển đổi thật sự không kịp

   Giai đoạn gia hạn mà Google công bố kết thúc vào ngày 1 tháng 11 năm 2026, và gia hạn được xin theo từng ứng dụng bị ảnh hưởng từ chính thông báo của ứng dụng đó. Sau ngày đó, con đường duy nhất là một bản dựng đạt chuẩn, nên đây không phải lý do để dừng phần việc kỹ thuật.

Cách xin gia hạn tới ngày 1 tháng 11 năm 2026

Nhà phát triển bị ảnh hưởng có thể xin một khoản gia hạn giữ cho việc phân phối chạy tới ngày 1 tháng 11 năm 2026. Bạn xin nó theo từng ứng dụng, từ cảnh báo chính sách của ứng dụng đó trong Play Console. Google không mô tả nó là tự động, được bảo đảm, hay là miễn trừ vĩnh viễn, nên hãy tiếp tục chuyển đổi trong lúc đơn còn đang chờ.

Google Play Console · ảnh chụp màn hình thật Bấm để phóng to

1. Mở ứng dụng bị ảnh hưởng trong Play Console

   Quyền xin gia hạn gắn theo từng ứng dụng chứ không theo cả tài khoản. Nếu bạn phát hành nhiều ứng dụng, hãy chuẩn bị lặp lại việc này cho từng ứng dụng bị ảnh hưởng.

   Đã kiểm chứng
2. Vào Trạng thái chính sách

   Chỉ những ứng dụng mà Google coi là chưa đạt mới mang mục cảnh báo về cấp API mục tiêu. Nếu ứng dụng đã đạt thì ở đây chẳng có gì để gia hạn và cũng không có biểu mẫu nào để tìm.

   Đã kiểm chứng
3. Mở cảnh báo hoặc phần chi tiết về cấp API mục tiêu

   Tiêu đề hiển thị trong ảnh chụp phía trên là App must target Android 16 (API level 36) or higher. Câu chữ vẫn có thể khác nhau theo từng ứng dụng và theo trạng thái triển khai, nên hãy xem đó là điều một tài khoản thật đã thấy chứ không phải một chuỗi phổ quát được bảo đảm.

   Đã kiểm chứng
4. Theo liên kết gia hạn trong mục cảnh báo, hoặc trong phần Thông báo

   Google dẫn một số nhà phát triển bị ảnh hưởng đi qua thông báo của ứng dụng thay vì qua khung cảnh báo. Hãy kiểm tra cả hai trước khi kết luận rằng lựa chọn đó không tồn tại với bạn.

   Đã kiểm chứng
5. Gửi thông tin được yêu cầu

   Google không công bố các câu hỏi chính xác trên trang trợ giúp công khai, nên hãy coi mọi danh sách kiểu "họ sẽ hỏi những gì" là chưa kiểm chứng. Hãy trả lời từ kế hoạch chuyển đổi thật của bạn.

   Một phần
6. Coi ngày 1 tháng 11 năm 2026 là điểm dừng cứng

   Gia hạn dời mốc chứ không bỏ yêu cầu. Những gì một gia hạn đã được cấp bao phủ đều phải hoàn tất chậm nhất vào ngày 1 tháng 11 năm 2026; sau đó, một tệp API 36 đạt chuẩn là cách duy nhất để nộp một bản cập nhật di động thông thường.

   Đã kiểm chứng
7. Vẫn tiếp tục chuyển đổi trong lúc đơn còn chờ

   Không có gì trong câu chữ của Google hứa hẹn được duyệt. Lập kế hoạch dựa trên một khoản gia hạn bạn chưa nhận là giả định đắt nhất có thể có trong chu kỳ này.

   Một phần

Còn một phân biệt nữa đáng giữ trong đầu: Google gắn chú thích về gia hạn vào yêu cầu API 36, và phần văn xuôi thường mô tả gia hạn như thứ giữ cho việc phân phối một ứng dụng hiện có tiếp tục chạy. Nó không đi qua từng tổ hợp ứng dụng mới, bản cập nhật và ứng dụng hiện có với cùng độ chính xác. Trước khi bạn cho rằng một khoản gia hạn bao trùm một bản tải lên cụ thể mà bạn đã lên kế hoạch, hãy đọc chính cảnh báo của ứng dụng bạn xem nó nói bao trùm cái gì.

Còn API 37 vào năm 2027 thì sao?

Google đã thông báo rằng ứng dụng mới và bản cập nhật sẽ phải nhắm tới cấp API 37 từ tháng 8 năm 2027. Bảng yêu cầu hiện hành chưa đưa ra ngày cụ thể hay ma trận ngoại lệ theo loại thiết bị cho năm 2027, nên bài này không tự đặt ra một ma trận như vậy. Lịch phát hành riêng của Android 17 (độ ổn định nền tảng dự kiến vào tháng 3 năm 2026, một bản phát hành lớn trong Q2 và một bản phát hành SDK nhỏ trong Q4) là một dòng thời gian khác với lịch cấp mục tiêu của Play; hãy tách bạch hai thứ này. Một phần: đã công bố tháng, chưa công bố ngày

Cách đưa một ứng dụng lên API 36

Bốn bước: cài SDK của API 36, nâng compileSdk và targetSdk lên 36, cập nhật những dependency vỡ khi bạn làm vậy, và kiểm thử các thay đổi hành vi của Android 16. Đổi con số chỉ là sửa một dòng. Chứng minh ứng dụng vẫn chạy được mới là cuộc chuyển đổi thật.

Bản cập nhật của tôi bị từ chối vì cấp API mục tiêu. Tôi cần sửa gì?

Hãy bắt đầu từ cấp API mục tiêu của phiên bản đã tải lên mà vấn đề nêu tên, rồi sửa bản dựng đã sinh ra nó. Các bước chuyển đổi chung bên dưới vẫn như cũ; đây là thứ tự thực hiện khi Play Console đã từ chối.

1. Đọc vấn đề. Mở vấn đề về API mục tiêu của ứng dụng trong Trạng thái chính sách (Policy status) và ghi lại version code mà nó nêu tên, cấp mục tiêu mà nó báo và mức sàn mà nó yêu cầu. Hãy lưu ảnh chụp màn hình đúng nội dung văn bản đó.

2. Kiểm tra tệp đó. Trong Test and release, Latest releases and bundles, mở phiên bản đó và đọc cấp API mục tiêu của nó. So sánh với nhánh, flavour hoặc bản xuất đã dựng ra nó. Tệp mới là bằng chứng; thiết lập trong trình biên tập thì không.

3. Sửa nơi sinh ra tệp. Nếu tệp thấp hơn 36, hãy cài nền tảng API 36 và nâng compileSdk và targetSdk, hoặc đi theo con đường framework hay bộ xuất dành cho nền tảng của bạn ở bên dưới. Để nguyên minSdk trừ khi công cụ hoặc thư viện phụ thuộc buộc phải có một thay đổi riêng.

4. Kiểm thử, rồi tải lên với version code cao hơn. Chạy bản dựng release đã ký trên Android 16 và trên phiên bản cũ nhất mà bạn hỗ trợ, nhất là sau khi framework thay đổi mức tối thiểu.

5. Đọc lại tệp mới. Xác nhận cấp mục tiêu của nó trong Play Console, xác nhận trạng thái bản phát hành, rồi mở lại vấn đề chính sách sau khi xử lý xong. Nếu cảnh báo vẫn nêu tên một phiên bản cũ hơn, hãy kiểm tra xem phiên bản đó còn đang chạy trên kênh nào; đừng xoá một kỳ thử nghiệm khép kín đang chạy chỉ để gỡ cảnh báo.

6. Vẫn bị chặn dù tệp đã đúng? Dùng đường trợ giúp của ứng dụng, kèm nội dung vấn đề, các version code, kênh và thông tin chi tiết về tệp. Đừng giả định rằng yêu cầu gia hạn đã được chấp thuận; phạm vi của nó lấy từ chính thông báo của ứng dụng đó.

Trung tâm trợ giúp Google Play Console về cách xem các phiên bản đã tải lên và về yêu cầu API mục tiêu, hướng dẫn cấu hình Android SDK, và các phản ánh của nhà phát triển về cảnh báo dai dẳng, tất cả đều được đọc vào ngày 15 tháng 10 năm 2026. Trình tự này là cách phân loại xử lý thực tế, không phải một bảng xếp hạng nguyên nhân đã được đo lường.

Bước 1: cài SDK Android 16

Mở Android Studio, vào SDK Manager, và cài Android SDK Platform cho cấp API 36 cùng bộ build tools 36.x.x hiện hành. Không cài nền tảng đó thì việc nâng compileSdk chỉ sinh ra một lỗi build trông chẳng liên quan gì tới việc bạn vừa làm.

Bước 2: nâng các cấp trong bản build của bạn

Chọn nền tảng của bạn. Đường dẫn tệp và các dòng cụ thể có khác nhau, nhưng đích đến thì không: bản kê khai bên trong bundle bạn tải lên phải khai target 36.

android {
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

android {
    compileSdk 36

    defaultConfig {
        applicationId "com.example.app"
        minSdkVersion 24
        targetSdkVersion 36
        versionCode 2
        versionName "1.0.1"
    }
}

android {
    compileSdk = flutter.compileSdkVersion
    compileSdk = 36

    defaultConfig {
        targetSdk = flutter.targetSdkVersion
        targetSdk = 36
    }
}

buildscript {
    ext {
        buildToolsVersion = "36.0.0"
        minSdkVersion = 24
        compileSdkVersion = 36
        targetSdkVersion = 36
    }
}

ext {
    minSdkVersion = 24
    compileSdkVersion = 36
    targetSdkVersion = 36
}

Bước 3: cập nhật dependency và công cụ của framework

Nâng cấp biên dịch là chỗ những dependency cũ gãy. Hãy chuẩn bị đụng tới Android Gradle Plugin, chính Gradle, Kotlin, các thư viện AndroidX, Google Play services, và mọi SDK quảng cáo hay phân tích có mang mã native. Bài này cố ý không công bố "các phiên bản đúng", vì các phiên bản tương thích đổi hằng tuần và một danh sách ghim cứng ở đây sẽ gây hiểu lầm trong vòng nửa tháng. Hãy lấy chúng từ ghi chú phát hành hiện hành của chính framework bạn dùng, vào đúng ngày bạn chuyển đổi.

Bước 4: dựng, tải lên và kiểm tra tệp

• Tạo một Android App Bundle đã ký và tăng mã phiên bản.
• Kiểm thử tệp release, không chỉ bản debug. Việc rút gọn mã và tài nguyên làm vỡ những thứ mà bản debug che đi.
• Tải lên đúng kênh dự định và xác nhận trong Play Console rằng tệp báo cấp API mục tiêu 36.
• Sau khi xử lý xong, rà lại mọi kênh đang hoạt động và mở lại Trạng thái chính sách.

Hành vi Android 16 cần kiểm thử trước khi tung API 36

Nhắm tới API 36 sẽ bật hành vi của Android 16 cho ứng dụng của bạn trên máy chạy Android 16. Các hành vi ưu tiên cao cần kiểm thử là layout edge-to-edge, điều hướng quay lại dự đoán, tự do xoay hướng trên màn lớn, quyền về sức khoẻ, lập lịch theo nhịp cố định và dàn chữ. Hãy tick những gì áp cho bạn bên dưới để nhận danh sách kiểm thử riêng cho ứng dụng của bạn thay vì một danh sách chung chung.

Edge-to-edge và quay lại dự đoán: bán kính ảnh hưởng rộng nhất

Edge-to-edge có bán kính ảnh hưởng rộng vì nó không đòi ứng dụng của bạn dùng bất kỳ API lạ nào. Trên Android 16, một ứng dụng nhắm tới API 36 không còn dùng được thuộc tính từ chối trước đây, nên nội dung vốn tưởng rằng các thanh hệ thống sẽ chừa chỗ nay chạy luồn xuống dưới chúng. Triệu chứng chỉ là chuyện thẩm mỹ, cho tới đúng lúc một nút chính nằm dưới thanh cử chỉ và không bấm được nữa.

Điều hướng quay lại dự đoán cũng có bán kính ảnh hưởng rộng tương tự. Nếu ứng dụng của bạn đăng ký cách xử lý quay lại kiểu cũ, luồng đó có thể đơn giản là không chạy như trước một khi quay lại dự đoán bật mặc định cho target 36. Hãy kiểm thử thao tác quay lại từ mọi độ sâu điều hướng bạn có: modal, WebView, biểu mẫu còn dữ liệu chưa lưu, và màn hình cuối trước khi thoát.

Điều gì không phải lỗi vỡ phổ quát của target 36

Còn yêu cầu về kích thước trang 16 KB thì sao?

Yêu cầu khác, mốc ngày khác, cùng nhóm ứng dụng. Hạn chót về cấp API mục tiêu nói về cấp mà bản kê khai của bạn khai báo. Yêu cầu về kích thước trang 16 KB nói về việc các thư viện native của bạn có chạy được trên thiết bị dùng trang bộ nhớ 16 KB hay không. Hướng dẫn hiện hành của Google nêu ngày 1 tháng 2 năm 2027 là mốc mà các bản cập nhật bị ảnh hưởng nếu chưa hỗ trợ 16 KB thì không còn phát hành được nữa.

• Ai bị ảnh hưởng: yêu cầu của Google áp cho ứng dụng nhắm tới API 35 trở lên trên thiết bị Google Play 64-bit. Trong nhóm đó, ứng dụng đóng gói thư viện native .so, trực tiếp hoặc qua một SDK, là nhóm nhiều khả năng phải dựng lại và căn chỉnh rõ ràng nhất. Nếu ứng dụng của bạn thuần Kotlin hoặc Java thì nhìn chung đã tương thích sẵn, nhưng vẫn nên kiểm thử thay vì cho là vậy.
• Nó không phải cái gì: nó không thuộc hạn chót cấp API mục tiêu ngày 31 tháng 8 năm 2026, và đạt cái này không có nghĩa là đạt cái kia.
• Vì sao chúng rơi cùng lúc: nâng cấp mục tiêu thường đồng nghĩa với việc dựng lại, và lần dựng lại chính là lúc một vấn đề kích thước trang độc lập của thư viện native lộ ra. Chính sự trùng thời điểm ấy khiến hai thứ bị nhầm lẫn.

Nếu ứng dụng của bạn có đóng gói thư viện native, hãy coi phần kiểm tra kích thước trang là một đầu việc riêng với vòng kiểm thử riêng thay vì thứ bạn nhét vào bản dựng API 36 vào phút chót. Hai thay đổi này chạm vào những phần khác nhau của bản build, và gỡ lỗi chúng cùng lúc là cách biến một cuộc chuyển đổi một tuần thành ba tuần.

Bạn đã tải API 36 lên mà cảnh báo vẫn còn đó

Thường là một trong ba chuyện: bundle chưa xử lý xong và Trạng thái chính sách chưa làm mới, một tệp cũ hơn vẫn nằm trên một kênh đang hoạt động khác, hoặc tệp bạn tải lên thật ra không khai 36 dù dự án của bạn có. Hãy đi từ trên xuống theo danh sách, và đừng bắt đầu xoá các bản phát hành.

Tiêu đề mà nhà phát triển đang báo về là Your app must target Android 16 (API level 36) or higher. Google không công bố một chuỗi lỗi chuẩn đầy đủ cho mọi luồng tải lên, nên hãy coi mọi câu chữ chính xác bạn tìm thấy trên mạng, kể cả câu này, là quan sát được chứ không phải chính thức.

Một thói quen sẽ xử lý dứt điểm phần lớn chuyện này: sau mỗi lần tải lên, hãy đọc lại cấp API mục tiêu từ chính tệp trong Play Console và ghi nó cạnh mã phiên bản. Việc đó mất mười giây và nó xoá sạch cả nhóm chuyện "tôi chắc chắn mình đã sửa rồi" khỏi tuần làm việc của bạn.

Danh sách kiểm tra trước hạn

Mười bốn mục, theo đúng thứ tự chúng thực sự diễn ra. Bốn mục cuối là những mục người ta hay bỏ qua, và cũng chính là những mục quyết định cảnh báo có biến mất hay không.

PrimeTestLab nằm ở đâu trong hạn chót này

Nói rõ ranh giới trước: chúng tôi không chuyển đổi mã của bạn. Nâng targetSdk, cập nhật dependency và sửa các thay đổi hành vi của Android 16 là phần build của bạn, và bài viết này là toàn bộ đóng góp của chúng tôi cho việc đó. Thứ chúng tôi lo là nửa còn lại của va chạm: 12 người thử nghiệm thật, duy trì tham gia liên tục 14 ngày mà một tài khoản cá nhân mới cần có trước khi chạm được tới bản phát hành công khai.

Vấn đề nằm ở thời điểm. Một người phát hành lần đầu đang bị yêu cầu làm cùng lúc hai việc khó không liên quan tới nhau: tung một bản dựng API 36, và giữ được một kỳ thử nghiệm khép kín hợp lệ suốt hai tuần liền. Bản dựng là bài toán kỹ thuật giải được. Tìm mười hai con người thật chịu tham gia liên tục mười bốn ngày, trên thiết bị thật, mới là phần lặng lẽ ngốn cả tháng.

Tự chạy thử nghiệm khép kín so với giao lại

Thứ tự nên làm

Nếu bạn đang đối mặt cả hai vấn đề cùng lúc, hãy chạy song song thay vì nối tiếp. Hãy bắt đầu kỳ thử nghiệm khép kín ngay, vì 14 ngày của nó là thời gian thực bạn không nén lại được, và làm việc chuyển đổi API 36 song song với nó. Đẩy bản dựng đạt chuẩn vào đúng kênh khép kín đó khi nó sẵn sàng, với mã phiên bản cao hơn và vẫn nguyên nhóm người thử nghiệm đang tham gia. Như vậy hạn chót và cửa sổ thử nghiệm thôi tranh nhau cùng một nửa tháng.

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

Tóm lại

Ảnh chụp chính sách đã được kiểm chứng ngày 9 tháng 8 năm 2026 và kiểm chứng lại ngày 15 tháng 10 năm 2026, đối chiếu với các trang hiện hành của Google về API mục tiêu, kích thước trang và thử nghiệm khép kín. Google cập nhật các trang này mà không báo trước, nên hãy kiểm tra các nguồn trực tiếp phía trên trước khi hành động dựa trên bất kỳ mốc ngày nào. Lần kiểm tra biên tập kế tiếp: sau khi giai đoạn gia hạn kết thúc vào ngày 1 tháng 11 năm 2026.