Khi phát hành Android 16 vào năm 2025, chúng tôi đã chia sẻ tầm nhìn của mình về một hệ sinh thái thiết bị, trong đó các ứng dụng thích ứng liền mạch với mọi màn hình, cho dù đó là điện thoại, thiết bị có thể gập lại, máy tính bảng, máy tính, màn hình ô tô hay XR. Người dùng mong muốn ứng dụng của họ hoạt động ở mọi nơi. Dù đa nhiệm trên máy tính bảng, mở thiết bị để đọc thoải mái hay chạy ứng dụng trong môi trường cửa sổ kiểu máy tính, người dùng đều muốn giao diện người dùng lấp đầy không gian hiển thị hiện có và thích ứng với tư thế của thiết bị.

Chúng tôi đã giới thiệu những thay đổi đáng kể đối với các API về hướng và khả năng thay đổi kích thước để tạo điều kiện cho hành vi thích ứng, đồng thời cung cấp lựa chọn không tham gia tạm thời để giúp bạn thực hiện quá trình chuyển đổi. Chúng tôi nhận thấy nhiều nhà phát triển đã thích ứng thành công với quá trình chuyển đổi này khi nhắm đến API cấp 36.

Giờ đây, với việc phát hành Android 17 Beta, chúng tôi sẽ chuyển sang giai đoạn tiếp theo trong lộ trình thích ứng của mình: Android 17 (cấp độ API 37) sẽ xoá lựa chọn không tham gia của nhà phát triển đối với các hạn chế về hướng và khả năng đổi kích thước trên thiết bị có màn hình lớn (sw > 600 dp). Khi nhắm đến cấp độ API mục tiêu 37, ứng dụng của bạn phải có khả năng thích ứng với nhiều kích thước màn hình.

Những thay đổi về hành vi này đảm bảo rằng hệ sinh thái Android mang đến trải nghiệm nhất quán và chất lượng cao trên mọi hệ số hình dạng thiết bị.

Những thay đổi trong Android 17

Các ứng dụng nhắm đến Android 17 phải đảm bảo khả năng tương thích với việc loại bỏ các thuộc tính tệp kê khai và API thời gian chạy được giới thiệu trong Android 16. Chúng tôi hiểu rằng đối với một số ứng dụng, đây có thể là một quá trình chuyển đổi lớn. Vì vậy, chúng tôi đã đưa ra các phương pháp hay nhất và công cụ giúp bạn tránh gặp phải các vấn đề thường gặp ở phần sau của bài đăng này trên blog.

Không có thay đổi mới nào kể từ Android 16, nhưng nhà phát triển không thể chọn không sử dụng nữa. Xin lưu ý: khi ứng dụng của bạn đang chạy trên màn hình lớn (màn hình lớn có nghĩa là kích thước nhỏ hơn của màn hình lớn hơn hoặc bằng 600 dp), các thuộc tính và API sau đây trong tệp kê khai sẽ bị bỏ qua:

Lưu ý: Như đã đề cập trước đó với Android 16, những thay đổi này không áp dụng cho các màn hình có kích thước nhỏ hơn 600 dp hoặc các ứng dụng được phân loại là Trò chơi dựa trên cờ android:appCategory. 

Ngoài ra, người dùng vẫn nắm quyền kiểm soát. Trong chế độ cài đặt tỷ lệ khung hình, người dùng có thể chọn sử dụng hành vi mà ứng dụng yêu cầu.

Chuẩn bị ứng dụng

Các ứng dụng sẽ cần hỗ trợ bố cục ngang và dọc cho các kích thước màn hình trong toàn bộ dải tỷ lệ khung hình mà người dùng có thể chọn sử dụng ứng dụng, bao gồm cả cửa sổ có thể đổi kích thước, vì sẽ không còn cách nào để hạn chế tỷ lệ khung hình và hướng thành dọc hoặc ngang.

Thử nghiệm ứng dụng

Bước đầu tiên là kiểm thử ứng dụng của bạn với những thay đổi này để đảm bảo ứng dụng hoạt động tốt trên nhiều kích thước màn hình.

Sử dụng Android 17 Beta 1 với trình mô phỏng Pixel Tablet và Pixel Fold trong Android Studio, đồng thời đặt targetSdkPreview = “CinnamonBun”. Ngoài ra, bạn có thể sử dụng khung tương thích bằng cách bật cờ UNIVERSAL_RESIZABLE_BY_DEFAULT nếu ứng dụng của bạn chưa nhắm đến cấp độ API mục tiêu 36.

Chúng tôi có các công cụ bổ sung để đảm bảo bố cục của bạn thích ứng đúng cách. Bạn có thể tự động kiểm tra giao diện người dùng và nhận các đề xuất để giúp giao diện người dùng thích ứng hơn bằng Compose UI Check, đồng thời mô phỏng các đặc điểm cụ thể của màn hình trong các quy trình kiểm thử bằng DeviceConfigurationOverride.

Đối với những ứng dụng từng hạn chế hướng và tỷ lệ khung hình, chúng tôi thường thấy các vấn đề về bản xem trước của camera bị lệch hoặc sai hướng, bố cục bị kéo giãn, nút không thể truy cập hoặc mất trạng thái người dùng khi xử lý các thay đổi về cấu hình. 

Hãy cùng xem xét một số chiến lược để giải quyết những vấn đề thường gặp này.

Đảm bảo khả năng tương thích với camera

Một vấn đề thường gặp trên thiết bị có thể gập lại ở chế độ ngang hoặc khi tính toán tỷ lệ khung hình trong các trường hợp như chế độ nhiều cửa sổ, cửa sổ kiểu máy tính hoặc màn hình được kết nối là khi bản xem trước của camera xuất hiện bị kéo giãn, xoay hoặc cắt.

Đảm bảo bản xem trước của camera không bị kéo giãn hoặc xoay.

Vấn đề này thường xảy ra trên các thiết bị có màn hình lớn và thiết bị có thể gập lại vì các ứng dụng giả định mối quan hệ cố định giữa các tính năng của camera (chẳng hạn như tỷ lệ khung hình và hướng cảm biến) và các tính năng của thiết bị (chẳng hạn như hướng thiết bị và hướng tự nhiên).

Để đảm bảo bản xem trước của camera thích ứng chính xác với mọi kích thước hoặc hướng cửa sổ, hãy cân nhắc 4 giải pháp sau:

Giải pháp 1: Jetpack CameraX (nên dùng) 

Giải pháp đơn giản và mạnh mẽ nhất là sử dụng thư viện Jetpack CameraX. Phần tử trên giao diện người dùng PreviewView được thiết kế để tự động xử lý mọi độ phức tạp của bản xem trước:

• PreviewView điều chỉnh chính xác theo hướng cảm biến, độ xoay thiết bị và tỷ lệ
• PreviewView duy trì tỷ lệ khung hình của hình ảnh từ camera, thường là bằng cách căn giữa và cắt (FILL_CENTER)
• Bạn có thể đặt loại tỷ lệ thành FIT_CENTER để tạo hiệu ứng hòm thư cho bản xem trước nếu cần

Để biết thêm thông tin, hãy xem phần Triển khai bản xem trước trong tài liệu về CameraX.

Giải pháp 2: CameraViewfinder 

Nếu đang sử dụng cơ sở mã Camera2 hiện có, thì thư viện CameraViewfinder (tương thích ngược với cấp độ API 21) là một giải pháp hiện đại khác. Thành phần này giúp đơn giản hoá việc hiển thị nguồn cấp dữ liệu từ camera bằng cách sử dụng TextureView hoặc SurfaceView và áp dụng tất cả các phép biến đổi cần thiết (tỷ lệ khung hình, tỷ lệ và hướng xoay) cho bạn.

Để biết thêm thông tin, hãy xem bài đăng trên blog Giới thiệu về kính ngắm của camera và hướng dẫn cho nhà phát triển về Bản xem trước của camera.

Giải pháp 3: Triển khai Camera2 theo cách thủ công 

Nếu không thể sử dụng CameraX hoặc CameraViewfinder, bạn phải tính toán hướng và tỷ lệ khung hình theo cách thủ công, đồng thời đảm bảo các phép tính được cập nhật mỗi khi có thay đổi về cấu hình:

• Lấy hướng cảm biến camera (ví dụ: 0, 90, 180, 270 độ) từ CameraCharacteristics
• Nhận chế độ xoay màn hình hiện tại của thiết bị (ví dụ: 0, 90, 180, 270 độ)
• Sử dụng các giá trị hướng của cảm biến camera và độ xoay màn hình để xác định các phép biến đổi cần thiết cho SurfaceView hoặc TextureView
• Đảm bảo tỷ lệ khung hình của đầu ra Surface khớp với tỷ lệ khung hình của bản xem trước camera để tránh bị biến dạng

Lưu ý quan trọng: Lưu ý rằng ứng dụng camera có thể đang chạy ở một phần màn hình, ở chế độ nhiều cửa sổ hoặc chế độ cửa sổ kiểu máy tính hoặc trên màn hình được kết nối. Vì lý do này, bạn không nên dùng kích thước màn hình để xác định kích thước của kính ngắm camera; thay vào đó, hãy dùng các chỉ số cửa sổ. Nếu không, bạn có nguy cơ gặp phải tình trạng bản xem trước của camera bị kéo giãn.

Để biết thêm thông tin, hãy xem hướng dẫn cho nhà phát triển về Bản xem trước của camera và video Ứng dụng Camera trên nhiều hệ số hình dạng.

Giải pháp 4: Thực hiện các thao tác cơ bản với camera bằng cách sử dụng một Intent 

Nếu không cần nhiều tính năng của camera, thì một giải pháp đơn giản và dễ hiểu là thực hiện các thao tác cơ bản với camera, chẳng hạn như chụp ảnh hoặc quay video bằng ứng dụng camera mặc định trên thiết bị. Trong trường hợp này, bạn chỉ cần dùng một Intent thay vì tích hợp với một thư viện camera để dễ dàng bảo trì và thích ứng hơn. 

Để biết thêm thông tin, hãy xem phần Ý định của máy ảnh.

Tránh giao diện người dùng bị kéo giãn hoặc các nút không thể truy cập

Nếu giả định ứng dụng của bạn có một hướng thiết bị hoặc tỷ lệ khung hình hiển thị cụ thể, thì ứng dụng có thể gặp phải vấn đề khi được dùng ở nhiều hướng hoặc kích thước cửa sổ.

Đảm bảo các nút, trường văn bản và các phần tử khác không bị kéo giãn trên màn hình lớn.

Bạn có thể đã đặt các nút, trường văn bản và thẻ thành fillMaxWidth hoặc match_parent.  Trên điện thoại, hình ảnh này trông rất đẹp. Tuy nhiên, trên máy tính bảng hoặc thiết bị có thể gập lại ở chế độ ngang, các thành phần giao diện người dùng sẽ kéo dài trên toàn bộ màn hình lớn. Trong Jetpack Compose, bạn có thể dùng đối tượng sửa đổi widthIn để đặt chiều rộng tối đa cho các thành phần nhằm tránh nội dung bị kéo giãn:

Box(
    contentAlignment = Alignment.Center,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching beyond 300dp
            .fillMaxWidth()        // Fills width up to 300dp
            .padding(16.dp)
    ) {
        // Your content
    }
}

Nếu người dùng mở ứng dụng của bạn ở chế độ ngang trên thiết bị có thể gập lại hoặc máy tính bảng, thì các nút thao tác như Lưu hoặc Đăng nhập ở cuối màn hình có thể bị hiển thị ngoài màn hình. Nếu vùng chứa không thể cuộn, người dùng có thể không tiếp tục được. Trong Jetpack Compose, bạn có thể thêm đối tượng sửa đổi verticalScroll vào thành phần của mình:

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)

Bằng cách kết hợp các quy tắc ràng buộc về chiều rộng tối đa với tính năng cuộn theo chiều dọc, bạn đảm bảo ứng dụng của mình vẫn hoạt động và sử dụng được, bất kể kích thước cửa sổ ứng dụng rộng hay hẹp.

Hãy xem hướng dẫn của chúng tôi về cách tạo bố cục thích ứng.

Duy trì trạng thái khi cấu hình thay đổi

Việc xoá các quy định hạn chế về hướng và tỷ lệ khung hình có nghĩa là kích thước cửa sổ của ứng dụng sẽ thay đổi thường xuyên hơn nhiều. Người dùng có thể xoay thiết bị, gấp/mở thiết bị hoặc đổi kích thước ứng dụng của bạn một cách linh hoạt ở chế độ chia đôi màn hình hoặc chế độ cửa sổ kiểu máy tính.

Theo mặc định, những thay đổi về cấu hình này sẽ huỷ và tạo lại hoạt động của bạn. Nếu ứng dụng của bạn không quản lý đúng sự kiện trong vòng đời này, người dùng sẽ có trải nghiệm không tốt: vị trí cuộn được đặt lại về đầu, các biểu mẫu điền một nửa bị xoá sạch và nhật ký điều hướng bị mất. Để đảm bảo trải nghiệm thích ứng liền mạch, điều quan trọng là ứng dụng của bạn phải duy trì trạng thái trong quá trình thay đổi cấu hình. Với Jetpack Compose, bạn có thể chọn không tạo lại và thay vào đó cho phép các thay đổi về kích thước cửa sổ kết hợp lại giao diện người dùng để phản ánh lượng không gian có sẵn mới.

Hãy xem hướng dẫn của chúng tôi về cách lưu trạng thái giao diện người dùng.

Nhắm đến API cấp 37 muộn nhất vào tháng 8 năm 2027

Nếu trước đây ứng dụng của bạn đã chọn không áp dụng những thay đổi này khi nhắm đến API cấp 36, thì ứng dụng của bạn sẽ chỉ chịu ảnh hưởng của việc xoá lựa chọn không áp dụng Android 17 sau khi ứng dụng của bạn nhắm đến API cấp 37. Để giúp bạn lên kế hoạch trước và điều chỉnh ứng dụng của mình cho phù hợp, sau đây là mốc thời gian những thay đổi này sẽ có hiệu lực:

• Android 17: Những thay đổi được mô tả ở trên sẽ là trải nghiệm cơ bản cho các thiết bị có màn hình lớn (chiều rộng màn hình nhỏ nhất > 600 dp) đối với những ứng dụng nhắm đến cấp độ API mục tiêu 37. Nhà phát triển sẽ không có lựa chọn không sử dụng.

Thời hạn để nhắm đến một cấp độ API cụ thể là dành riêng cho từng cửa hàng ứng dụng. Đối với Google Play, các ứng dụng và bản cập nhật mới sẽ bắt buộc phải nhắm đến cấp độ API mục tiêu 37. Do đó, hành vi này là bắt buộc đối với việc phân phối vào tháng 8 năm 2027.

Chuẩn bị cho Android 17

Hãy tham khảo trang thay đổi của Android 17 để biết tất cả các thay đổi ảnh hưởng đến ứng dụng trong Android 17. Để kiểm thử ứng dụng, hãy tải Android 17 Beta 1 xuống và cập nhật lên targetSdkPreview = “CinnamonBun” hoặc sử dụng khung tương thích của ứng dụng để bật các thay đổi cụ thể.

Android sẽ ngày càng thích ứng hơn và chúng tôi luôn sẵn sàng hỗ trợ bạn đạt được mục tiêu đó. Khi chuẩn bị cho Android 17, bạn nên xem hướng dẫn của chúng tôi về cách tạo bố cục thích ứng và nguyên tắc về chất lượng đối với màn hình lớn. Những tài nguyên này được thiết kế để giúp bạn tự tin xử lý nhiều kiểu dáng và kích thước cửa sổ.

Đừng chần chừ. Hãy bắt đầu chuẩn bị cho Android 17 ngay hôm nay!