Khi phát hành Android 16 vào năm 2025, chúng tôi đã chia sẻ tầm nhìn 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 – 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 đợi ứng dụng của họ hoạt động ở mọi nơi. Dù đang thực hiện đa nhiệm trên máy tính bảng, mở thiết bị để đọc một cách 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 mong đợi giao diện người dùng sẽ 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 hướng và khả năng đổ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 tạm thời không tham gia để giúp bạn thực hiện quá trình chuyển đổi. Chúng tôi đã 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 đang chuyển sang giai đoạn tiếp theo của lộ trình thích ứng: Android 17 (cấp độ API 37) 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 các 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.

Các thay đổi về hành vi đả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 tất cả các kiểu 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ỏ 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 đây có thể là một quá trình chuyển đổi lớn đối với một số ứng dụng. Vì vậy, chúng tôi đã đưa vào các phương pháp hay nhất và công cụ để giúp tránh các vấn đề thường gặp sau này trong bài đăng này trên blog.

Không có thay đổi mới nào được giới thiệu kể từ Android 16, nhưng nhà phát triển không còn có thể chọn không tham gia. Xin nhắc lại: 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 tệp kê khai và API sau đây 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 nhỏ hơn sw 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 giữ quyền kiểm soát. Trong phần 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 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 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 của ứng dụng 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 đề xuất để làm cho giao diện người dùng thích ứng hơn bằng Compose UI Check và mô phỏng các đặc điểm hiển thị cụ thể trong các bài kiểm thử bằng DeviceConfigurationOverride.

Đối với các ứng dụng trước đây 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 máy ảnh bị lệch hoặc sai hướng, bố cục bị kéo giãn, nút không thể 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 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 máy ảnh

Một vấn đề thường gặp trên các thiết bị có thể gập lại theo hướng ngang hoặc để tính toán tỷ lệ khung hình trong các tình huống như 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 Máy ảnh xuất hiện bị kéo giãn, xoay hoặc cắt.

Đảm bảo bản xem trước của máy ảnh 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 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 máy ảnh thích ứng đúng cách 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ử trên giao diện người dùng PreviewView được thiết kế để tự động xử lý tất cả các độ 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 máy ảnh, 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 hộp 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 CameraX.

Giải pháp 2: CameraViewfinder 

Nếu bạn đ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ư việ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à 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 máy ảnh và hướng dẫn cho nhà phát triển về Bản xem trước của máy ảnh.

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 trên mỗi thay đổi về cấu hình:

• Lấy hướng cảm biến của máy ảnh (ví dụ: 0, 90, 180, 270 độ) từ CameraCharacteristics
• Lấy giá trị 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ảm biến của máy ảnh và giá trị 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 của máy ảnh để tránh bị méo

Quan trọng: Lưu ý rằng ứng dụng máy ảnh có thể đang chạy trong một phần của 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 các chỉ số về cửa sổ. Nếu không, bạn có nguy cơ bản xem trước của máy ảnh 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 máy ảnh và video Ứng dụng máy ảnh của bạn trên nhiều kiểu dáng.

Giải pháp 4: Thực hiện các thao tác cơ bản với máy ảnh bằng cách sử dụng Ý định 

Nếu không cần nhiều tính năng của máy ảnh, 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 máy ảnh, chẳng hạn như chụp ảnh hoặc quay video bằng ứng dụng máy ảnh mặc định trên thiết bị. Trong trường hợp này, bạn chỉ cần sử dụng 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 nút không thể truy cập

Nếu ứng dụng của bạn giả định một hướng thiết bị hoặc tỷ lệ khung hình màn hình cụ thể, thì ứng dụng có thể gặp vấn đề khi được sử dụng trên 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 thành phần 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, điều 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 giãn 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 ở 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ể được hiển thị ngoài màn hình. Nếu vùng chứa không thể cuộn, thì người dùng có thể bị chặn không thể 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 giới hạn về chiều rộng tối đa với tính năng cuộn dọc, bạn đảm bảo ứng dụng của mình vẫn hoạt động và có thể sử dụng được, bất kể kích thước cửa sổ ứng dụng trở nên rộng hay hẹp.

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

Giữ nguyên trạng thái khi thay đổi cấu hình

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. 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 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ẽ hủy bỏ 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 cách sự kiện trong vòng đời này, thì người dùng sẽ có trải nghiệm khó chịu: 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 giữ nguyên trạng thái thông qua những thay đổi về cấu hình này. 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 mới có sẵn.

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 trước tháng 8 năm 2027

Nếu trước đây ứng dụng của bạn chọn không tham gia những thay đổi này khi nhắm đến API cấp 36, thì ứng dụng của bạn sẽ chỉ bị ảnh hưởng bởi việc loại bỏ lựa chọn không tham gia 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à thực hiện các điều chỉnh cần thiết cho ứng dụng, sau đây là mốc thời gian mà những thay đổi này sẽ có hiệu lực:

• Android 17: Các 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 các ứ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 tham gia.

Thời hạn nhắm đến một cấp độ API cụ thể là dành riêng cho 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ẽ 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

Tham khảo trang các thay đổi trong 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 khả năng tương thích của ứng dụng để bật các thay đổi cụ thể.

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

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