Chuẩn bị ứng dụng của bạn cho những thay đổi về hướng và khả năng đổi kích thước trong Android 17

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ù là khi làm nhiều việc cùng lúc 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 quan trọng đối với các API hướng và khả năng đổi kích thước để hỗ trợ hành vi thích ứng, đồng thời cung cấp một lựa chọn 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 thay đổi này khi nhắm đến API cấp 36.

Giờ đây, khi phát hành Android 17 Beta, chúng tôi sẽ chuyển sang giai đoạn tiếp theo của lộ trình thích ứng: Android 17 (cấp độ API 37) sẽ loại bỏ lựa chọn không tham gia của nhà phát triển đối với các quy tắc hạn chế về hướng và khả năng đổi kích thước trên thiết bị 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 kiểu dáng thiết bị.

Những thay đổi trong Android 17

Ứ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ỏ dần 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 tham gia nữa. Xin lưu ý: khi ứng dụng của bạn đang chạy trên màn hình lớn (trong đó 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 tệp kê khai sau đây sẽ bị bỏ qua:

Lưu ý: Như đã đề cập trước đó về Android 16, những thay đổi này không áp dụng cho màn hình nhỏ hơn sw 600 dp hoặ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

Ứng dụng sẽ cần hỗ trợ bố cục ngang và dọc cho kích thước màn hình trong toàn bộ phạm vi 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 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 mọi 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 chính xác. 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 đề như 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 truy cập được 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 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 của 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 thiết bị 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 máy ảnh (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ị (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 (ưu tiên) 

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ử giao diện người dùng PreviewView được thiết kế để tự động xử lý mọi vấn đề phức tạp khi 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 do camera chụp, 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 API cấp 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
• Lấy chế độ xoay màn hình hiện tại của thiết bị (ví dụ: 0, 90, 180, 270 độ)
• Sử dụng giá trị hướng của cảm biến máy ảnh 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 máy ảnh để tránh bị méo

Quan trọng: Xin lưu ý rằng ứng dụng camera có thể đang chạy trên một phần màn hình, ở chế độ nhiều cửa sổ hoặc 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 sử dụng kích thước màn hình để xác định kích thước của kính ngắm máy ảnh; thay vào đó, hãy sử dụng 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 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 sử dụng một Intent thay vì tích hợp với thư viện máy ảnh để dễ dàng bảo trì và thích ứng. 

Để 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 truy cập được

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, giao diện này trông rất đẹp. Tuy nhiên, trên máy tính bảng hoặc thiết bị gập ở chế độ ngang, các phần tử trê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ể sử 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 theo hướng 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 hành động như Lưu hoặc Đăng nhập ở cuối màn hình có thể 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ể bị chặn tiếp tụ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 tắc 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 tham gia 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ề lưu trạng thái giao diện người dùng.

Nhắm đến cấp độ API mục tiêu 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 tham gia các thay đổi này khi nhắm đến cấp độ API mục tiêu 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 tham gia Android 17 sau khi ứng dụng của bạn nhắm đến cấp độ API mục tiêu 37. Để giúp bạn lên kế hoạch trước và thực hiện những điều chỉnh cần thiết cho ứng dụng, 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 mô tả ở trên sẽ là trải nghiệm cơ bản cho các thiết bị màn hình lớn (chiều rộng màn hình nhỏ nhất > 600 dp) đối với các ứng dụng nhắm đến API cấp 37. Nhà phát triển sẽ không có lựa chọn không tham gia.

Thời hạn nhắm đến một cấp độ API cụ thể tuỳ thuộc vào từng cửa hàng ứng dụng. Đối với Google Play, các ứng dụng mới và bản cập nhật sẽ bắt buộc phải nhắm đến cấp độ API mục tiêu 37, khiến hành vi này trở thành bắt buộ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ẽ thích ứng với mọi nhu cầu của bạn và chúng tôi luôn sẵn sàng trợ giúp bạn. Trong quá trình 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 trên 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!