Perubahan perilaku: semua aplikasi

Platform Android 12 menyertakan perubahan perilaku yang dapat memengaruhi aplikasi Anda. Perubahan perilaku berikut ini berlaku untuk semua aplikasi saat dijalankan di Android 12, terlepas dari targetSdkVersion aplikasi. Sebaiknya uji aplikasi Anda lalu modifikasi sesuai kebutuhan untuk mendukung perubahan ini dengan tepat, jika memungkinkan.

Selain itu, pastikan Anda meninjau daftar perubahan perilaku yang hanya memengaruhi aplikasi yang menargetkan Android 12.

Pengalaman pengguna

Efek overscroll regangan

Pada perangkat yang menjalankan Android 12 dan yang lebih tinggi, perilaku visual untuk peristiwa overscroll berubah.

Pada Android 11 dan yang lebih lama, peristiwa overscroll menyebabkan elemen visual memiliki glow; sementara di Android 12 dan yang lebih tinggi, elemen visual meregang dan memantul kembali pada peristiwa tarik, lalu mengayun dan memantul kembali saat peristiwa ayun.

Untuk informasi selengkapnya, lihat panduan untuk menganimasikan gestur scroll.

Layar pembuka aplikasi

Jika sebelumnya telah menerapkan layar pembuka kustom di Android 11 atau yang lebih lama, Anda harus memigrasikan aplikasi ke API SplashScreen untuk memastikannya ditampilkan dengan benar mulai di Android 12. Jika Anda tidak memigrasikan aplikasi, pengalaman peluncuran aplikasi yang telah didegradasi atau tidak diinginkan akan terjadi.

Untuk mengetahui petunjuknya, lihat Memigrasikan implementasi layar pembuka yang ada ke Android 12.

Mulai Android 12, sistem selalu menerapkan layar pembuka default sistem Android baru di cold dan warm start untuk semua aplikasi. Secara default, layar pembuka default sistem ini dibuat menggunakan elemen ikon peluncur aplikasi Anda dan windowBackground tema Anda (jika satu warna).

Untuk mengetahui detail selengkapnya, lihat panduan developer layar pembuka.

Resolusi intent web

Mulai Android 12 (API level 31), intent web generik berubah menjadi aktivitas dalam aplikasi Anda hanya jika aplikasi disetujui untuk domain tertentu yang terdapat dalam intent web tersebut. Jika aplikasi Anda untuk domain tidak disetujui, intent web akan ditetapkan ke aplikasi browser default pengguna.

Aplikasi dapat memperoleh persetujuan ini dengan melakukan salah satu hal berikut:

Verifikasi domain menggunakan Link Aplikasi Android.

Pada aplikasi yang menargetkan Android 12 atau yang lebih baru, sistem akan mengubah cara verifikasi otomatis Android App Links aplikasi Anda. Dalam filter intent aplikasi, pastikan Anda menyertakan kategori BROWSABLE dan mendukung skema https.

Di Android 12 atau yang lebih baru, Anda dapat melakukan verifikasi manual pada Link Aplikasi Android aplikasi Anda untuk menguji pengaruh logika yang diperbarui ini terhadap aplikasi Anda.
Minta pengguna mengaitkan aplikasi Anda dengan domain di setelan sistem.

Jika aplikasi Anda memanggil intent web, pertimbangkan untuk menambahkan perintah atau dialog yang meminta pengguna untuk mengonfirmasi tindakan.

Peningkatan mode imersif untuk navigasi gestur

Android 12 menggabungkan perilaku yang ada untuk memudahkan pengguna melakukan perintah navigasi gestur saat dalam mode imersif. Selain itu, Android 12 menyediakan perilaku kompatibilitas mundur untuk mode imersif melekat.

Display#getRealSize dan getRealMetrics: penghentian penggunaan dan batasan

Perangkat Android tersedia dalam berbagai faktor bentuk, seperti layar besar, tablet, dan perangkat foldable. Untuk merender konten dari setiap perangkat dengan tepat, aplikasi Anda harus menentukan ukuran layar atau tampilan. Seiring waktu, Android telah menyediakan API yang berbeda untuk mengambil informasi ini. Di Android 11, kami memperkenalkan API WindowMetrics dan menghentikan metode berikut:

Di Android 12, kami terus merekomendasikan penggunaan WindowMetrics, dan akan menghentikan metode ini:

Untuk mengurangi perilaku aplikasi yang menggunakan Display API guna mengambil batas aplikasi, Android 12 membatasi nilai yang ditampilkan oleh API untuk aplikasi yang tidak sepenuhnya dapat diubah ukurannya. Hal ini dapat memengaruhi aplikasi yang menggunakan informasi ini dengan MediaProjection.

Aplikasi harus menggunakan API WindowMetrics untuk membuat kueri batas jendelanya, dan Configuration.densityDpi untuk membuat kueri kepadatan saat ini.

Untuk kompatibilitas yang lebih luas dengan versi Android yang lebih lama, Anda dapat menggunakan Jetpack WindowManager yang menyertakan WindowMetrics yang mendukung Android 4.0 (API level 14) dan yang lebih baru.

Contoh cara menggunakan WindowMetrics

Pertama, pastikan aktivitas aplikasi Anda dapat sepenuhnya diubah ukurannya.

Aktivitas harus mengandalkan WindowMetrics dari konteks aktivitas untuk semua pekerjaan terkait UI, terutama WindowManager.getCurrentWindowMetrics() atau WindowMetricsCalculator.computeCurrentWindowMetrics() Jetpack.

Jika aplikasi Anda membuat MediaProjection, batas harus memiliki ukuran yang tepat karena proyeksi menangkap partisi tampilan tempat aplikasi proyektor berjalan.

Jika aplikasi dapat sepenuhnya diubah ukurannya, konteks aktivitas akan menampilkan batas yang benar seperti berikut:

Kotlin

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

Java

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

Jika aplikasi tidak sepenuhnya dapat diubah ukurannya, aplikasi harus membuat kueri dari instance WindowContext dan mengambil WindowMetrics batas aktivitas menggunakan WindowManager.getMaximumWindowMetrics() atau metode Jetpack WindowMetricsCalculator.computeMaximumWindowMetrics().

Kotlin

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Java

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

Semua aplikasi dalam mode multi-aplikasi

Android 12 membuat perilaku standar mode multi-aplikasi.

Pada perangkat layar besar (sw >= 600 dp), platform mendukung semua aplikasi dalam mode multi-aplikasi, terlepas dari konfigurasi aplikasi. Jika resizeableActivity="false", aplikasi dialihkan ke mode kompatibilitas saat diperlukan untuk mengakomodasi dimensi tampilan.

Pada layar kecil (sw < 600dp), sistem akan memeriksa minWidth dan minHeight aktivitas untuk menentukan apakah aktivitas dapat berjalan dalam mode multi-aplikasi. Jika resizeableActivity="false", aplikasi tidak dapat berjalan dalam mode multi-aplikasi, terlepas dari lebar dan tinggi minimum.

Untuk mengetahui informasi selengkapnya, lihat Dukungan multi-aplikasi.

Pratinjau kamera di layar besar

Aplikasi kamera umumnya mengasumsikan hubungan tetap antara orientasi perangkat dan rasio lebar tinggi pratinjau kamera. Namun, faktor bentuk layar besar, seperti perangkat foldable, dan mode tampilan seperti multi-aplikasi dan multi-tampilan, menantang asumsi tersebut.

Di Android 12, aplikasi kamera yang meminta orientasi layar tertentu dan tidak dapat diubah ukurannya (resizeableActivity="false") secara otomatis memasuki mode potret inset, yang memastikan orientasi dan rasio tinggi lebar yang tepat dari pratinjau kamera. Pada perangkat foldable dan perangkat lain yang memiliki Hardware Abstraction Layer (HAL) kamera, rotasi tambahan diterapkan pada output kamera untuk mengompensasi orientasi sensor kamera, dan output kamera dipangkas untuk menyesuaikan dengan rasio lebar tinggi pratinjau kamera aplikasi. Pemangkasan dan rotasi tambahan memastikan presentasi pratinjau kamera yang tepat terlepas dari orientasi perangkat dan status perangkat dilipat atau dibentangkan.

Penundaan UX untuk notifikasi layanan latar depan

Guna memberikan pengalaman yang disederhanakan untuk layanan latar depan jangka pendek, perangkat yang menjalankan Android 12 atau yang lebih baru dapat menunda tampilan notifikasi layanan latar depan selama 10 detik, dengan beberapa pengecualian. Perubahan ini memberikan kesempatan untuk tugas jangka pendek agar dapat diselesaikan sebelum notifikasi muncul.

Performa

Bucket Aplikasi Standby Terbatas

Android 11 (API level 30) memperkenalkan bucket yang dibatasi sebagai Bucket Aplikasi Standby. Mulai di Android 12, bucket ini aktif secara default. Bucket yang dibatasi memiliki prioritas terendah (dan pembatasan tertinggi) di antara semua bucket. Bucket dengan urutan prioritas dari tinggi ke rendah adalah:

Active: Aplikasi sedang atau baru saja digunakan
Working set: Aplikasi digunakan secara rutin
Frequent: Aplikasi sering digunakan, tetapi tidak setiap hari
Rare: Aplikasi tidak sering digunakan
Restricted: Aplikasi menghabiskan banyak resource sistem, atau mungkin menunjukkan perilaku yang tidak diinginkan.

Sistem mempertimbangkan perilaku aplikasi, selain pola penggunaan, untuk memutuskan apakah akan menempatkan aplikasi di bucket yang dibatasi atau tidak.

Aplikasi Anda kemungkinan tidak ditempatkan di bucket yang dibatasi jika aplikasi menggunakan resource sistem secara lebih bertanggung jawab. Selain itu, sistem menempatkan aplikasi dalam bucket yang tidak terlalu dibatasi jika pengguna berinteraksi langsung dengan aplikasi Anda.

Memastikan aplikasi Anda berada di bucket yang dibatasi

Untuk memeriksa apakah sistem telah menempatkan aplikasi Anda di bucket yang dibatasi, panggil getAppStandbyBucket(). Jika nilai hasil dari metode ini adalah STANDBY_BUCKET_RESTRICTED, aplikasi Anda berada di bucket yang dibatasi.

Menguji perilaku bucket yang dibatasi

Untuk menguji perilaku aplikasi saat sistem menempatkan aplikasi ke dalam bucket yang dibatasi, Anda dapat memindahkan aplikasi ke bucket tersebut secara manual. Untuk melakukannya, jalankan perintah berikut di jendela terminal:

adb shell am set-standby-bucket PACKAGE_NAME restricted

Keamanan dan privasi

Perkiraan lokasi

Dialog ini memiliki dua kumpulan opsi, satu di atas
yang lain — **Gambar 1.** Dialog izin sistem yang memungkinkan pengguna memberikan informasi perkiraan lokasi.

Di perangkat yang menjalankan Android 12 atau yang lebih tinggi, pengguna dapat meminta agar aplikasi Anda memiliki akses hanya ke informasi perkiraan lokasi.

Jika aplikasi Anda meminta izin runtime ACCESS_FINE_LOCATION, Anda juga harus meminta izin ACCESS_COARSE_LOCATION untuk menangani kasus saat pengguna memberikan akses perkiraan lokasi ke aplikasi. Anda harus menyertakan kedua izin dalam satu permintaan runtime.

Dialog izin sistem menyertakan opsi berikut untuk pengguna, seperti ditunjukkan dalam gambar 1:

Akurat: Memberikan akses ke informasi lokasi akurat.
Perkiraan: Hanya memberikan akses ke informasi perkiraan lokasi.

Tombol mikrofon dan kamera

Perangkat yang didukung yang menjalankan Android 12 atau yang lebih baru memungkinkan pengguna untuk mengaktifkan dan menonaktifkan kamera dan akses mikrofon untuk semua aplikasi di perangkat dengan menekan satu opsi beralih. Pengguna dapat mengakses opsi yang dapat dialihkan dari Setelan Cepat, seperti yang ditunjukkan dalam gambar 1 atau dari layar Privasi di setelan sistem.

Pelajari tombol beralih ini lebih lanjut, dan cara memeriksa apakah aplikasi Anda mengikuti praktik terbaik terkait CAMERA dan RECORD_AUDIO.

Indikator mikrofon dan kamera

Pada perangkat yang menjalankan Android 12 atau yang lebih baru, saat aplikasi mengakses mikrofon atau kamera, ikon akan muncul di status bar.

Pelajari indikator ini lebih lanjut dan cara memeriksa apakah aplikasi Anda mengikuti praktik terbaik terkait izin CAMERA dan RECORD_AUDIO.

Kotak setelan cepat diberi label 'Camera access' dan
'Mic access' — **Gambar 2.** Tombol mikrofon dan kamera di Setelan Cepat.

Kotak persegi panjang di pojok kanan atas, yang
mencakup ikon kamera dan ikon mikrofon — **Gambar 3.** Indikator mikrofon dan kamera yang menampilkan akses data terbaru.

Visibilitas paket izin

Pada perangkat yang menjalankan Android 12 atau yang lebih baru, aplikasi yang menargetkan Android 11 (API level 30) atau yang lebih baru dan yang memanggil salah satu metode berikut menerima kumpulan hasil yang difilter, berdasarkan visibilitas paket aplikasi ke aplikasi lain:

Penerapan BouncyCastle dihapus

Android 12 menghapus banyak implementasi BouncyCastle algoritme kriptografi yang sebelumnya tidak digunakan lagi, termasuk semua algoritme AES. Sebagai gantinya, sistem akan menggunakan implementasi Conscrypt dari algoritme ini.

Perubahan ini memengaruhi aplikasi Anda jika salah satu kondisi berikut benar:

Aplikasi Anda menggunakan ukuran kunci 512-bit. Conscrypt tidak mendukung ukuran kunci ini. Jika perlu, perbarui logika kriptografi aplikasi Anda agar dapat menggunakan ukuran kunci yang berbeda.
Aplikasi Anda menggunakan ukuran kunci yang tidak valid dengan KeyGenerator. Implementasi Conscrypt KeyGenerator menjalankan validasi tambahan pada parameter kunci jika dibandingkan dengan BouncyCastle. Misalnya, Conscrypt tidak mengizinkan aplikasi Anda untuk membuat kunci AES 64-bit karena AES hanya mendukung kunci 128-, 192-, dan 256-bit.

BouncyCastle memungkinkan untuk membuat kunci dengan ukuran yang tidak valid, tetapi akan gagal jika kunci ini digunakan dengan Cipher. Conscrypt gagal lebih awal.
Anda melakukan inisialisasi cipher Mode Galois/Penghitung (GCM) menggunakan ukuran selain 12 byte. Implementasi Conscrypt GcmParameterSpec memerlukan inisialisasi 12 byte yang direkomendasikan oleh NIST.

Notifikasi akses papan klip

Di Android 12 dan yang lebih baru, saat aplikasi memanggil getPrimaryClip() untuk mengakses data klip dari aplikasi lain untuk pertama kalinya, pesan toast memberi tahu pengguna tentang akses papan klip ini.

Teks di dalam pesan toast berisi format berikut: APP pasted from your clipboard.

Informasi tentang teks dalam deskripsi klip

Di Android 12 dan yang lebih baru, getPrimaryClipDescription() dapat mendeteksi detail berikut:

Teks bergaya, menggunakan isStyledText().
Klasifikasi teks yang berbeda, seperti URL, menggunakan getConfidenceScore().

Aplikasi tidak dapat menutup dialog sistem

Untuk meningkatkan kontrol pengguna saat berinteraksi dengan aplikasi dan sistem, tindakan intent ACTION_CLOSE_SYSTEM_DIALOGS tidak digunakan lagi di Android 12. Kecuali untuk beberapa kasus khusus, saat aplikasi mencoba memanggil intent yang berisi tindakan ini, sistem akan melakukan salah satu hal berikut berdasarkan versi SDK target aplikasi:

Jika aplikasi menargetkan Android 12 atau yang lebih baru, SecurityException akan terjadi.

Jika aplikasi menargetkan Android 11 (API level 30) atau yang lebih rendah, intent tidak akan dijalankan, dan pesan berikut muncul di Logcat:

E ActivityTaskManager Permission Denial: \
android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
dropping broadcast.

Pengecualian

Dalam kasus berikut, aplikasi masih dapat menutup dialog sistem di Android 12 atau yang lebih baru:

Aplikasi Anda menjalankan uji instrumentasi.
Aplikasi menargetkan Android 11 atau yang lebih rendah dan menampilkan jendela yang berada di atas panel samping notifikasi.

Catatan: Jika aplikasi menargetkan Android 12, Anda tidak perlu menggunakan ACTION_CLOSE_SYSTEM_DIALOGS dalam situasi ini. Alasannya, jika aplikasi Anda memanggilstartActivity() saat jendela berada di atas panel samping notifikasi, sistem akan menutup panel samping notifikasi secara otomatis.
Aplikasi Anda menargetkan Android 11 atau yang lebih rendah. Sebagai tambahan, pengguna telah berinteraksi dengan notifikasi yang mungkin menggunakan tombol tindakan notifikasi, dan aplikasi Anda sedang memproses layanan atau penerima siaran sebagai respons terhadap tindakan pengguna tersebut.
Aplikasi Anda menargetkan Android 11 atau yang lebih rendah dan memiliki layanan aksesibilitas aktif. Jika aplikasi Anda menargetkan Android 12 dan ingin menutup baris notifikasi, gunakan tindakan aksesibilitas GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE.

Peristiwa sentuh yang tidak tepercaya diblokir

Untuk menjaga keamanan sistem dan pengalaman pengguna yang baik, Android 12 mencegah aplikasi menggunakan peristiwa sentuh ketika overlay menutupi aplikasi dengan cara berbahaya. Dengan kata lain, sistem memblokir sentuhan yang melewati jendela tertentu, dengan beberapa pengecualian.

Aplikasi yang terkena dampak

Perubahan ini memengaruhi aplikasi yang memilih untuk membiarkan sentuhan melewati jendelanya, misalnya dengan menggunakan tanda FLAG_NOT_TOUCHABLE. Beberapa contoh mencakup, tetapi tidak terbatas pada, hal berikut:

Overlay yang memerlukan izin SYSTEM_ALERT_WINDOW, seperti jendela yang menggunakan TYPE_APPLICATION_OVERLAY, dan menggunakan tanda FLAG_NOT_TOUCHABLE.
Jendela aktivitas yang menggunakan tanda FLAG_NOT_TOUCHABLE.

Pengecualian

Dalam kasus berikut, sentuhan "pass-through" diizinkan:

Interaksi dalam aplikasi Anda. Aplikasi Anda menampilkan overlay, dan overlay hanya muncul saat pengguna berinteraksi dengan aplikasi Anda.
Jendela tepercaya. Jendela ini mencakup (tetapi tidak terbatas pada) hal-hal berikut:
Catatan: Jenis jendelaTYPE_APPLICATION_OVERLAY tidak tepercaya.
Jendela yang tidak terlihat. Tampilan root jendela adalah GONE atau INVISIBLE.
Jendela yang sepenuhnya transparan. Properti alpha untuk jendela adalah 0,0.
Jendela pemberitahuan sistem yang cukup transparan. Sistem menganggap sekumpulan jendela peringatan sistem sudah cukup transparan jika opasitas gabungan kurang dari atau sama dengan opasitas kabur maksimum sistem untuk sentuhan. Di Android 12, opasitas maksimum ini adalah 0,8 secara default.

Mendeteksi saat sentuhan yang tidak dipercaya diblokir

Jika tindakan sentuh diblokir oleh sistem, log Logcat akan mencatat pesan berikut:

Untrusted touch due to occlusion by PACKAGE_NAME

Menguji perubahan

Sentuhan tidak tepercaya diblokir secara default di perangkat yang menjalankan Android 12 atau yang lebih baru. Untuk mengizinkan sentuhan tidak tepercaya, jalankan perintah ADB berikut di jendela terminal:

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

Untuk mengembalikan perilaku ke default (sentuhan tidak tepercaya diblokir), jalankan perintah berikut:

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

Siklus proses aktivitas

Aktivitas peluncur root tidak lagi diselesaikan dengan menekan Kembali

Android 12 mengubah penanganan default sistem. Tekan Kembali pada aktivitas peluncur yang berada di root tugasnya. Pada versi sebelumnya, sistem akan menyelesaikan aktivitas ini ketika tombol Kembali ditekan. Di Android 12, sistem kini memindahkan aktivitas dan tugasnya ke latar belakang, bukan menyelesaikan aktivitas. Perilaku baru mencocokkan perilaku saat ini saat keluar dari aplikasi menggunakan gestur atau tombol Layar utama.

Untuk sebagian besar aplikasi, perubahan ini berarti pengguna yang menggunakan tombol Kembali untuk keluar dari aplikasi Anda dapat melanjutkan aplikasi dari status warm dengan lebih cepat, bukan memulai ulang aplikasi sepenuhnya dari status cold.

Sebaiknya uji aplikasi Anda dengan perubahan ini. Jika saat ini aplikasi Anda mengganti onBackPressed() untuk menangani navigasi Kembali dan menyelesaikan Activity, update implementasi Anda untuk memanggil ke super.onBackPressed(), bukan menyelesaikan. Memanggil super.onBackPressed() akan memindahkan aktivitas dan tugasnya ke latar belakang jika sesuai dan memberikan pengalaman navigasi yang lebih konsisten untuk pengguna di seluruh aplikasi.

Perhatikan juga bahwa, secara umum, sebaiknya gunakan AndroidX Activity API untuk menyediakan navigasi kembali kustom, bukan mengganti onBackPressed(). AndroidX Activity API otomatis tunduk pada perilaku sistem yang sesuai jika tidak ada komponen yang melakukan intersepsi tombol Kembali sistem.

Grafik dan gambar

Peningkatan peralihan kecepatan refresh

Di Android 12, perubahan kecepatan refresh yang menggunakan setFrameRate() dapat terjadi terlepas dari apakah layar mendukung transisi yang lancar ke kecepatan refresh baru; transisi yang lancar adalah transisi yang tidak memiliki gangguan visual, seperti layar hitam selama satu atau dua detik. Sebelumnya, jika tampilan tidak mendukung transisi yang lancar, biasanya tampilan akan terus menggunakan kecepatan refresh yang sama setelah setFrameRate() dipanggil. Anda dapat menentukan di awal apakah transisi ke refresh baru akan lancar dengan memanggil getAlternativeRefreshRates(). Umumnya, callback onDisplayChanged() akan dipanggil setelah tombol kecepatan refresh selesai, tetapi untuk beberapa tampilan yang terhubung secara eksternal, callback tersebut akan dipanggil selama transisi tidak lancar.

Berikut ini contoh cara menerapkannya:

Kotlin

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

Java

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

Konektivitas

Update Passpoint

API berikut ditambahkan ke Android 12:

isPasspointTermsAndConditionsSupported().Persyaratan dan ketentuan merupakan fitur Passpoint yang memungkinkan deployment jaringan untuk menggantikan captive portal yang tidak aman, yang menggunakan jaringan terbuka, dengan jaringan Passpoint yang aman. Notifikasi ditampilkan kepada pengguna ketika persyaratan dan ketentuan harus disetujui. Aplikasi yang menyarankan jaringan Passpoint yang dilindungi oleh persyaratan dan ketentuan harus memanggil API ini terlebih dahulu untuk memastikan bahwa perangkat mendukung kemampuan tersebut. Jika perangkat tidak mendukung kemampuan tersebut, perangkat tidak akan dapat terhubung ke jaringan ini, dan jaringan alternatif atau lama harus disarankan.
isDecoratedIdentitySupported(): Saat mengautentikasi ke jaringan dengan dekorasi awalan, awalan identitas yang didekorasi memungkinkan operator jaringan memperbarui Network Access Identifier (NAI) untuk melakukan perutean eksplisit melalui beberapa proxy di dalam jaringan AAA (lihat RFC 7542 untuk informasi selengkapnya).

Android 12 menerapkan fitur ini agar sesuai dengan spesifikasi WBA untuk ekstensi PPS-MO. Aplikasi yang menyarankan jaringan Passpoint yang memerlukan identitas yang didekorasi harus memanggil API ini terlebih dahulu untuk memastikan bahwa perangkat mendukung kemampuan tersebut. Jika perangkat tidak mendukung kemampuan tersebut, identitas tidak akan didekorasi dan autentikasi ke jaringan mungkin akan gagal.

Untuk membuat saran Passpoint, aplikasi harus menggunakan class PasspointConfiguration, Credential, dan HomeSp. Class ini menjelaskan profil Passpoint, yang ditentukan dalam spesifikasi Passpoint Aliansi Wi-Fi.

Untuk mengetahui informasi selengkapnya, lihat Wi-Fi suggestion API untuk konektivitas internet.

Pembatasan antarmuka non-SDK yang diupdate

Android 12 menyertakan daftar terbaru antarmuka non-SDK yang dibatasi berdasarkan kolaborasi dengan developer Android dan pengujian internal terbaru. Jika memungkinkan, kami akan memastikan ketersediaan alternatif publik sebelum membatasi antarmuka non-SDK.

Jika aplikasi Anda tidak menargetkan Android 12, beberapa perubahan ini mungkin tidak langsung memengaruhi Anda. Namun, meskipun saat ini Anda dapat menggunakan beberapa antarmuka non-SDK (bergantung pada API level target aplikasi Anda), penggunaan metode atau kolom non-SDK tetap sangat berisiko merusak aplikasi Anda.

Jika tidak yakin apakah aplikasi Anda menggunakan antarmuka non-SDK atau tidak, Anda dapat menguji aplikasi untuk mencari tahu. Jika aplikasi Anda mengandalkan antarmuka non-SDK, sebaiknya mulailah merencanakan migrasi ke alternatif SDK. Meskipun begitu, kami paham bahwa beberapa aplikasi memiliki kasus penggunaan yang valid untuk menggunakan antarmuka non-SDK. Jika tidak dapat menemukan alternatif penggunaan antarmuka non-SDK untuk fitur dalam aplikasi Anda, sebaiknya minta API publik baru.

Untuk mempelajari perubahan dalam rilis Android ini lebih lanjut, baca Pembaruan pembatasan antarmuka non-SDK di Android 12. Untuk mempelajari lebih lanjut antarmuka non-SDK secara umum, baca Pembatasan antarmuka non-SDK.