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

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

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

Perubahan perilaku memastikan 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 atribut manifes dan API runtime yang diperkenalkan di Android 16. Kami memahami bahwa transisi ini mungkin besar bagi beberapa aplikasi, jadi kami menyertakan praktik terbaik dan alat untuk membantu menghindari masalah umum di bagian akhir postingan blog ini.

Tidak ada perubahan baru yang diperkenalkan sejak Android 16, tetapi opsi tidak ikut developer tidak lagi tersedia. 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 manifes dan API berikut akan 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 flag 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 layar dalam rentang rasio aspek lengkap 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 adalah menguji aplikasi Anda 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, lalu tetapkan targetSdkPreview = “CinnamonBun”. Atau, Anda dapat menggunakan framework kompatibilitas aplikasi dengan mengaktifkan flag UNIVERSAL_RESIZABLE_BY_DEFAULT jika aplikasi Anda belum menargetkan API level 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 lebih adaptif dengan Pemeriksaan UI Compose, serta menyimulasikan karakteristik tampilan tertentu dalam pengujian menggunakan DeviceConfigurationOverride.

Untuk aplikasi yang secara historis membatasi orientasi dan rasio aspek, kami biasanya melihat masalah dengan pratinjau kamera yang miring atau salah orientasi, tata letak yang direntangkan, 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, jendela desktop, atau layar terhubung, adalah saat pratinjau kamera muncul direntangkan, diputar, atau dipangkas.

Pastikan pratinjau kamera Anda tidak direntangkan atau diputar.

Masalah ini sering terjadi pada perangkat layar besar dan perangkat 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 ke ukuran atau orientasi jendela apa pun, pertimbangkan empat solusi berikut:

Solusi 1: Jetpack CameraX (pilihan) 

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

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

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

Solusi 2: CameraViewfinder 

Jika Anda menggunakan codebase Camera2 yang ada, library CameraViewfinder (kompatibel mundur ke API level 21) adalah solusi modern lainnya. Library 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: Implementasi Camera2 manual 

Jika 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
• Dapatkan 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 Surface output 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 jendela desktop maupun di layar 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 di berbagai faktor bentuk.

Solusi 4: Melakukan tindakan kamera dasar menggunakan Intent 

Jika 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 dapat menggunakan Intent saja, bukan berintegrasi dengan library kamera, untuk memudahkan pemeliharaan dan kemampuan beradaptasi. 

Untuk mengetahui informasi selengkapnya, lihat Intent kamera.

Menghindari UI yang direntangkan atau tombol yang tidak dapat diakses

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

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

Anda mungkin telah menetapkan tombol, kolom teks, dan kartu ke fillMaxWidth atau match_parent. Di ponsel, tampilan ini bagus. Namun, di tablet atau perangkat foldable dalam mode 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 direntangkan:

  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 diblokir untuk melanjutkan. Di Jetpack Compose, Anda dapat menambahkan pengubah verticalScroll ke komponen:

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

Dengan menggabungkan batasan lebar maksimum 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 jauh lebih sering. Pengguna dapat memutar perangkat, melipat/membentangkannya, atau mengubah ukuran aplikasi Anda secara dinamis dalam mode multi-aplikasi 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 membuat frustrasi: posisi scroll direset ke bagian atas, formulir yang terisi sebagian dihapus, dan histori navigasi 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 menyusun ulang UI guna mencerminkan jumlah ruang baru yang tersedia.

Lihat panduan kami tentang menyimpan status UI.

Menargetkan API level 37 pada Agustus 2027

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

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

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

Mempersiapkan Android 17

Lihat halaman perubahan Android 17 untuk mengetahui semua perubahan yang memengaruhi aplikasi di Android 17. Untuk menguji aplikasi, 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 mencapainya. 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 lagi. Mulai bersiap untuk Android 17 hari ini.