Dengan rilis Android 16 pada tahun 2025, kami membagikan visi kami untuk ekosistem perangkat tempat aplikasi beradaptasi dengan lancar ke layar apa pun—baik itu ponsel, perangkat foldable, tablet, desktop, layar mobil, atau XR. Pengguna berharap aplikasi mereka berfungsi di mana saja. Baik saat melakukan multitasking di tablet, membentangkan perangkat untuk membaca dengan nyaman, atau menjalankan aplikasi di lingkungan jendela desktop, pengguna mengharapkan UI mengisi ruang tampilan yang tersedia dan beradaptasi dengan postur perangkat.

Kami memperkenalkan perubahan signifikan pada API orientasi dan pengubahan ukuran untuk memfasilitasi perilaku adaptif, sekaligus memberikan opsi penonaktifan sementara untuk membantu Anda melakukan transisi. Kami telah melihat banyak developer berhasil beradaptasi dengan transisi ini saat menargetkan level API 36.

Sekarang dengan rilis Android 17 Beta, kami beralih ke fase berikutnya dalam peta adaptif kami: Android 17 (API level 37) menghapus penonaktifan developer untuk pembatasan orientasi dan perubahan ukuran pada perangkat layar besar (sw > 600 dp). Saat menargetkan level API 37, aplikasi Anda harus dapat beradaptasi dengan berbagai ukuran layar.

Perubahan perilaku ini memastikan bahwa ekosistem Android menawarkan pengalaman yang konsisten dan berkualitas tinggi di semua faktor bentuk perangkat.

Perubahan di Android 17

Aplikasi yang menargetkan Android 17 harus memastikan kompatibilitasnya dengan penghentian penggunaan atribut manifes dan API runtime yang diperkenalkan di Android 16. Kami memahami bahwa bagi beberapa aplikasi, ini mungkin merupakan transisi besar. Oleh karena itu, kami menyertakan praktik terbaik dan alat untuk membantu menghindari masalah umum di bagian selanjutnya dalam postingan blog ini.

Tidak ada perubahan baru yang diperkenalkan sejak Android 16, tetapi developer tidak dapat lagi memilih untuk tidak menggunakan fitur ini. Sebagai pengingat: saat aplikasi Anda berjalan di layar besar—dengan layar besar berarti dimensi layar yang lebih kecil lebih besar dari atau sama dengan 600 dp—atribut dan API manifes berikut diabaikan:

Catatan: Seperti yang disebutkan sebelumnya dengan Android 16, perubahan ini tidak berlaku untuk layar yang lebih kecil dari sw 600 dp atau aplikasi yang dikategorikan sebagai game berdasarkan tanda android:appCategory. 

Selain itu, pengguna tetap memiliki kontrol. Di setelan rasio aspek, pengguna dapat secara eksplisit memilih untuk menggunakan perilaku yang diminta aplikasi.

Menyiapkan aplikasi

Aplikasi harus mendukung tata letak lanskap dan potret untuk ukuran tampilan dalam rentang rasio aspek penuh yang dapat dipilih pengguna untuk menggunakan aplikasi, termasuk jendela yang dapat diubah ukurannya, karena tidak akan ada lagi cara untuk membatasi rasio aspek dan orientasi ke potret atau lanskap.

Menguji aplikasi

Langkah pertama Anda adalah menguji aplikasi dengan perubahan ini untuk memastikan aplikasi berfungsi dengan baik di berbagai ukuran layar.

Gunakan Android 17 Beta 1 dengan emulator seri Pixel Tablet dan Pixel Fold di Android Studio, dan tetapkan targetSdkPreview = “CinnamonBun”. Atau, Anda dapat menggunakan framework kompatibilitas aplikasi dengan mengaktifkan tanda UNIVERSAL_RESIZABLE_BY_DEFAULT jika aplikasi Anda belum menargetkan level API 36.

Kami memiliki alat tambahan untuk memastikan tata letak Anda beradaptasi dengan benar. Anda dapat mengaudit UI secara otomatis dan mendapatkan saran untuk membuat UI Anda lebih adaptif dengan Compose UI Check, dan menyimulasikan karakteristik tampilan tertentu dalam pengujian menggunakan DeviceConfigurationOverride.

Untuk aplikasi yang secara historis membatasi orientasi dan rasio aspek, kami sering melihat masalah pada pratinjau kamera yang miring atau salah orientasi, tata letak yang meregang, tombol yang tidak dapat diakses, atau hilangnya status pengguna saat menangani perubahan konfigurasi. 

Mari kita lihat beberapa strategi untuk mengatasi masalah umum ini.

Memastikan kompatibilitas kamera

Masalah umum pada perangkat foldable lanskap atau untuk perhitungan rasio aspek dalam skenario seperti multi-aplikasi, mode jendela desktop, atau layar terhubung, adalah saat pratinjau kamera tampak direntangkan, diputar, atau dipangkas.

Pastikan pratinjau kamera Anda tidak diregangkan atau diputar.

Masalah ini sering terjadi di perangkat layar besar dan foldable karena aplikasi mengasumsikan hubungan tetap antara fitur kamera (seperti rasio aspek dan orientasi sensor) dan fitur perangkat (seperti orientasi perangkat dan orientasi alami).

Untuk memastikan pratinjau kamera Anda beradaptasi dengan benar terhadap ukuran atau orientasi jendela apa pun, pertimbangkan empat solusi berikut:

Solusi 1: Jetpack CameraX (disarankan) 

Solusi yang paling sederhana dan andal adalah menggunakan library Jetpack CameraX. Elemen UI PreviewView dirancang untuk menangani semua kompleksitas pratinjau secara otomatis:

• PreviewView menyesuaikan dengan benar untuk orientasi sensor, rotasi perangkat, dan penskalaan
• PreviewView mempertahankan rasio aspek gambar kamera, biasanya dengan memusatkan dan memangkas (FILL_CENTER)
• Anda dapat menetapkan jenis skala ke FIT_CENTER untuk menampilkan pratinjau dalam format lebar jika diperlukan

Untuk mengetahui informasi selengkapnya, lihat Menerapkan pratinjau dalam dokumentasi CameraX.

Solusi 2: CameraViewfinder 

Jika Anda menggunakan codebase Camera2 yang sudah ada, library CameraViewfinder (kompatibel mundur ke level API 21) adalah solusi modern lainnya. Hal ini menyederhanakan tampilan feed kamera dengan menggunakan TextureView atau SurfaceView dan menerapkan semua transformasi yang diperlukan (rasio aspek, skala, dan rotasi) untuk Anda.

Untuk mengetahui informasi selengkapnya, lihat postingan blog Memperkenalkan Jendela Bidik Kamera dan panduan developer Pratinjau kamera.

Solusi 3: Penerapan Camera2 secara manual 

Jika Anda tidak dapat menggunakan CameraX atau CameraViewfinder, Anda harus menghitung orientasi dan rasio aspek secara manual serta memastikan perhitungan diperbarui pada setiap perubahan konfigurasi:

• Dapatkan orientasi sensor kamera (misalnya, 0, 90, 180, 270 derajat) dari CameraCharacteristics
• Mendapatkan rotasi layar perangkat saat ini (misalnya, 0, 90, 180, 270 derajat)
• Gunakan nilai orientasi sensor kamera dan rotasi layar untuk menentukan transformasi yang diperlukan untuk SurfaceView atau TextureView
• Pastikan rasio aspek output Surface Anda cocok dengan rasio aspek pratinjau kamera untuk mencegah distorsi

Penting: Perhatikan bahwa aplikasi kamera mungkin berjalan di sebagian layar, baik dalam mode multi-aplikasi atau mode windowing desktop atau di layar yang terhubung. Oleh karena itu, ukuran layar tidak boleh digunakan untuk menentukan dimensi jendela bidik kamera; gunakan metrik jendela sebagai gantinya. Jika tidak, Anda berisiko mendapatkan pratinjau kamera yang direntangkan.

Untuk mengetahui informasi selengkapnya, lihat panduan developer Pratinjau kamera dan video Aplikasi Kamera Anda pada berbagai faktor bentuk.

Solusi 4: Lakukan tindakan kamera dasar menggunakan Intent 

Jika Anda tidak memerlukan banyak fitur kamera, solusi yang sederhana dan mudah adalah melakukan tindakan kamera dasar seperti mengambil foto atau merekam video menggunakan aplikasi kamera default perangkat. Dalam hal ini, Anda cukup menggunakan Intent, bukan mengintegrasikan dengan library kamera, untuk memudahkan pemeliharaan dan kemampuan beradaptasi. 

Untuk mengetahui informasi selengkapnya, lihat Intent kamera.

Hindari UI yang terentang atau tombol yang tidak dapat diakses

Jika aplikasi Anda mengasumsikan orientasi perangkat atau rasio aspek layar tertentu, aplikasi dapat mengalami masalah saat digunakan di berbagai orientasi atau ukuran jendela.

Pastikan tombol, kolom teks, dan elemen lainnya tidak diregangkan di layar besar.

Anda mungkin telah menyetel tombol, kolom teks, dan kartu ke fillMaxWidth atau match_parent.  Di ponsel, tampilannya sangat bagus. Namun, di tablet atau perangkat foldable dalam orientasi lanskap, elemen UI direntangkan di seluruh layar besar. Di Jetpack Compose, Anda dapat menggunakan pengubah widthIn untuk menetapkan lebar maksimum komponen guna menghindari konten yang diregangkan:

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

Jika pengguna membuka aplikasi Anda dalam orientasi lanskap di perangkat foldable atau tablet, tombol tindakan seperti Simpan atau Login di bagian bawah layar mungkin dirender di luar layar. Jika penampung tidak dapat di-scroll, pengguna dapat dicegah untuk melanjutkan. Di Jetpack Compose, Anda dapat menambahkan pengubah verticalScroll ke komponen:

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

Dengan menggabungkan batasan max-width dengan scrolling vertikal, Anda memastikan aplikasi tetap berfungsi dan dapat digunakan, terlepas dari seberapa lebar atau pendek ukuran jendela aplikasi.

Lihat panduan kami tentang membangun tata letak adaptif.

Mempertahankan status dengan perubahan konfigurasi

Menghapus batasan orientasi dan rasio aspek berarti ukuran jendela aplikasi Anda akan berubah lebih sering. Pengguna dapat memutar perangkat, melipat/membuka lipatannya, atau mengubah ukuran aplikasi Anda secara dinamis dalam mode layar terpisah atau jendela desktop.

Secara default, perubahan konfigurasi ini akan menghancurkan dan membuat ulang aktivitas Anda. Jika aplikasi Anda tidak mengelola peristiwa siklus proses ini dengan benar, pengguna akan mengalami pengalaman yang menjengkelkan: posisi scroll direset ke atas, formulir yang setengah terisi akan dihapus, dan histori navigasi akan hilang. Untuk memastikan pengalaman adaptif yang lancar, aplikasi Anda harus mempertahankan status melalui perubahan konfigurasi ini. Dengan Jetpack Compose, Anda dapat memilih untuk tidak membuat ulang, dan sebagai gantinya, mengizinkan perubahan ukuran jendela untuk merekomposisi UI Anda guna mencerminkan jumlah ruang baru yang tersedia.

Lihat panduan kami tentang menyimpan status UI.

Menargetkan level API 37 paling lambat Agustus 2027

Jika sebelumnya aplikasi Anda memilih tidak ikut perubahan ini saat menargetkan level API 36, aplikasi Anda hanya akan terpengaruh oleh penghapusan pilihan tidak ikut Android 17 setelah aplikasi Anda menargetkan level API 37. Untuk membantu Anda merencanakan dan melakukan penyesuaian yang diperlukan pada aplikasi, berikut adalah jadwal penerapan perubahan ini:

• Android 17: Perubahan yang dijelaskan di atas akan menjadi pengalaman dasar untuk perangkat layar besar (lebar layar terkecil > 600 dp) untuk aplikasi yang menargetkan level API 37. Developer tidak akan memiliki opsi untuk memilih tidak ikut.

Batas waktu untuk menargetkan level API tertentu bergantung pada app store. Untuk Google Play, aplikasi dan update baru akan diwajibkan untuk menargetkan API level 37, sehingga perilaku ini wajib untuk didistribusikan pada Agustus 2027.

Mempersiapkan Android 17

Lihat halaman perubahan Android 17 untuk mengetahui semua perubahan yang memengaruhi aplikasi di Android 17. Untuk menguji aplikasi Anda, download Android 17 Beta 1 dan update ke targetSdkPreview = “CinnamonBun” atau gunakan framework kompatibilitas aplikasi untuk mengaktifkan perubahan tertentu.

Masa depan Android bersifat adaptif, dan kami siap membantu Anda mewujudkannya. Saat Anda bersiap untuk Android 17, sebaiknya tinjau panduan kami untuk membangun tata letak adaptif dan pedoman kualitas layar besar. Referensi ini dirancang untuk membantu Anda menangani beberapa faktor bentuk dan ukuran jendela dengan percaya diri.

Jangan tunda. Mulai bersiap untuk Android 17 sekarang juga.