Chuẩn bị ứng dụng cho những thay đổi về khả năng đổi kích thước và hướng 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 về một hệ sinh thái thiết bị, nơi 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ị gập, 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 đã đưa ra 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 quá trình chuyển đổi này khi nhắm đến cấp độ API mục tiêu 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 đảm bảo rằng hệ sinh thái Android mang lại trải nghiệm nhất quán, 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 sự chuyển đổi lớn. Vì vậy, chúng tôi đã đưa các phương pháp hay nhất và công cụ vào bài đăng trên blog này để giúp bạn tránh các vấn đề thường gặp sau này.

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 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

Ứ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 dòng Pixel Tablet và Pixel Fold trong Android Studio, rồ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 API cấp 36.

Chúng tôi có thêm các công cụ để đả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 đề xuất để giao diện người dùng thích ứng hơn bằng Kiểm tra giao diện người dùng Compose, đồng thời 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 những ứng dụng trước đây có hướng và tỷ lệ khung hình bị hạn chế, 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 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 theo hướng ngang hoặc khi tính toán tỷ lệ khung hình trong các trường hợp 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 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ị 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 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à hiệu quả 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 hướng cảm biến, chế độ xoay thiết bị và tỷ lệ
• PreviewView duy trì tỷ lệ khung hình của hình ảnh camera, thường 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 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 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à chế độ 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 theo từng thay đổi về cấu hình:

• Lấy hướng cảm biến máy ảnh (ví dụ: 0, 90, 180, 270 độ) từ CameraCharacteristics
• Lấy góc xoay hiện tại của màn hình thiết bị (ví dụ: 0, 90, 180, 270 độ)
• Sử dụng 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 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 bản xem trước 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 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 một Ý định 

Nếu bạn 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 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 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 hiển thị cụ thể, thì ứng dụng có thể gặp vấn đề khi được 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, 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 thao tác cuộn 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 ngắn đến mức nào.

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 đồng nghĩa với việc 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 một cách linh động ở 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 cách sự kiện trong vòng đời này, người dùng sẽ có trải nghiệm không hài lòng: vị trí cuộn được đặt lại về đầu trang, 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 thông qua các thay đổi về cấu hình này. Với Jetpack Compose, bạn có thể chọn không tham gia tạo lại mà cho phép thay đổi kích thước cửa sổ để kết hợp lại giao diện người dùng nhằm 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 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 những 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 loại bỏ lựa chọn không tham gia trên Android 17 sau khi ứng dụng 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ể sẽ tuỳ theo 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

Tham khảo trang thay đổi trên Android 17 để biết tất cả thay đổi ảnh hưởng đến ứng dụng trên 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ể.

Tương lai của Android là khả năng thích ứng và chúng tôi sẵn sàng trợ giúp bạn đạt được điều đó. 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 xây dựng 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!