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

Perilaku untuk peristiwa overscroll mengalami perubahan di Android 12. Lihat Efek Overscroll untuk informasi selengkapnya.

Penundaan UX notifikasi layanan latar depan

Guna memberikan pengalaman yang disederhanakan untuklayanan latar depan jangka pendek di Android 12, sistem dapat menunda tampilan notifikasi layanan latar depan selama 10 detik untuk layanan latar depan tertentu. Perubahan ini memberikan kesempatan untuk tugas jangka pendek agar dapat diselesaikan sebelum notifikasi muncul.

Jika layanan latar depan memiliki setidaknya salah satu dari karakteristik berikut, sistem akan segera menampilkan notifikasi terkait setelah layanan dimulai:

Layanan ini dikaitkan dengan notifikasi yang menyertakan tombol tindakan.
Layanan memiliki foregroundServiceType dari mediaPlayback, mediaProjection, atau phoneCall.
Layanan ini menyediakan kasus penggunaan yang berkaitan dengan panggilan telepon, navigasi, atau pemutaran media, seperti yang dijelaskan dalam atribut kategori notifikasi.
Layanan memilih tidak menggunakan perubahan perilaku dengan meneruskan FOREGROUND_SERVICE_IMMEDIATE ke setForegroundServiceBehavior() saat menyiapkan notifikasi.

Peningkatan mode imersif untuk navigasi gestur

Android 12 menyederhanakan mode imersif guna membuat navigasi gestur lebih mudah dan lebih konsisten dengan pengalaman aktivitas lainnya, seperti menonton video dan membaca buku. Untuk mempelajari lebih lanjut, lihat entri yang sesuai pada halaman fitur.

Resolusi intent web

Untuk memberikan pengalaman yang lebih sederhana saat pengguna memilih link web, Android 12 akan membuka intent web tertentu di browser default pengguna jika intent tersebut berisi domain yang tidak disetujui. Aplikasi Anda untuk domain yang menggunakan salah satu pendekatan berikut dapat disetujui:

Verifikasi domain menggunakan Link Aplikasi Android.
Meminta pengguna menghubungkan aplikasi dengan domain.

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

Pelajari perubahan pada resolusi intent web lebih lanjut.

Bucket Aplikasi Standby Terbatas

Bucket Aplikasi Standby membantu sistem memprioritaskan permintaan sumber daya aplikasi berdasarkan seberapa baru dan seberapa sering aplikasi digunakan.

Setiap bucket mewakili sebuah prioritas. Prioritas yang rendah berarti sistem menerapkan lebih banyak pembatasan dalam menjalankan aplikasi Anda.

Mulai versi Android 12, tersedia bucket baru bernama bucket yang dibatasi. 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
Dibatasi

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.

Sistem menempatkan aplikasi dalam keranjang yang tidak terlalu dibatasi jika pengguna berinteraksi langsung dengan aplikasi Anda.

Pembatasan pengelolaan daya

Jika sistem menempatkan aplikasi Anda di bucket yang dibatasi, pembatasan berikut berlaku:

Anda dapat menjalankan tugas satu kali per hari, dalam sesi yang berdurasi 10 menit. Selama sesi ini, sistem akan mengelompokkan pekerjaan aplikasi Anda dengan tugas aplikasi lain.
Aplikasi Anda dapat menjalankan lebih sedikit tugas yang dipercepat , dibandingkan dengan saat sistem menempatkan aplikasi dalam bucket yang tidak terlalu dibatasi.
Alarm inexact dari aplikasi Anda dikirimkan satu kali per hari. Anda membuat alarm yang tidak eksak saat memanggil set(), setInexactRepeating(), setAndAllowWhileIdle(), atau setWindow() metode.
Aplikasi Anda dapat menerima lima pesan Firebase Cloud Messaging (FCM) berprioritas tinggi per hari secara tepat waktu. Semua pesan FCM berikutnya dikirim dengan prioritas normal. Jadi, pesan mungkin akan tertunda jika perangkat berada dalam mode hemat daya.

Jatah layanan latar depan

Jika sistem menempatkan aplikasi di bucket yang dibatasi, aplikasi Anda tetap dapat menjalankan layanan latar depan. Namun, jika menargetkan Android 12, aplikasi Anda masih terpengaruh oleh pembatasan peluncuran layanan latar depan.

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

Display#getRealSize dan getRealMetrics: penghentian penggunaan and sandboxing

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 akan menyediakan API yang berbeda untuk mengambil informasi ini. Di Android 11, kami memperkenalkan API WindowMetrics dan metode berikut tidak digunakan lagi:

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 menambahkan mekanisme sandbox baru untuk memperbaiki informasi yang ditampilkan oleh API ini. 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.

Suatu aktivitas harus mengandalkan WindowMetrics dari konteks aktivitas untuk pekerjaan terkait UI apa pun, terutama WindowManager.getCurrentWindowMetrics().

Jika aplikasi Anda membuat MediaProjection, batas ukuran harus benar karena proyeksi akan menangkap tampilan. Jika aplikasi dapat sepenuhnya diubah ukurannya, konteks aktivitas akan menampilkan batas yang benar seperti berikut:

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

Jika aplikasi tidak dapat sepenuhnya diubah ukurannya, aplikasi harus membuat kueri batas dari instance WindowContext tersebut, dan mengambil WindowMetrics dari area tampilan maksimum yang tersedia untuk aplikasi menggunakan WindowManager.getMaximumWindowMetrics()

Context windowContext = mContext.createWindowContext(mContext.getDisplay(),
        TYPE_APPLICATION, null /* options */);
WindowMetrics projectionMetrics = windowContext.getWindowManager()
        .getMaximumWindowMetrics();

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

Keamanan dan privasi

Tombol beralih mikrofon dan kamera

Kotak setelan cepat diberi label 'Akses kamera' dan
'Akses mikrofon' — **Gambar 1.** Tombol mikrofon dan kamera di Setelan Cepat.

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

Tombol kamera dan mikrofon memengaruhi semua aplikasi di perangkat:

Saat pengguna menonaktifkan akses kamera, aplikasi akan menerima feed kamera kosong.
Saat pengguna menonaktifkan akses mikrofon, aplikasi akan menerima audio senyap. Selain itu, sensor gerakan memiliki batas kecepatan, terlepas dari apakah Anda mendeklarasikan izin HIGH_SAMPLING_RATE_SENSORS atau tidak.

Catatan: Saat pengguna melakukan panggilan ke layanan darurat, seperti 911, sistem akan mengaktifkan akses mikrofon. Perilaku ini akan menjaga keamanan pengguna.

Saat pengguna menonaktifkan akses ke kamera atau mikrofon, lalu meluncurkan aplikasi yang memerlukan akses ke informasi kamera atau mikrofon, sistem akan mengingatkan pengguna bahwa tombol di seluruh perangkat dinonaktifkan.

Memastikan perangkat tertentu mendukung tombol beralih mikrofon dan kamera

Untuk memeriksa apakah perangkat mendukung tombol mikrofon dan kamera, tambahkan logika yang muncul di cuplikan kode berikut:

Kotlin

val sensorPrivacyManager = applicationContext
        .getSystemService(SensorPrivacyManager::class.java)
        as SensorPrivacyManager
val supportsMicrophoneToggle = sensorPrivacyManager
        .supportsSensorToggle(Sensors.MICROPHONE)
val supportsCameraToggle = sensorPrivacyManager
        .supportsSensorToggle(Sensors.CAMERA)

Java

SensorPrivacyManager sensorPrivacyManager = getApplicationContext()
        .getSystemService(SensorPrivacyManager.class);
boolean supportsMicrophoneToggle = sensorPrivacyManager
        .supportsSensorToggle(Sensors.MICROPHONE);
boolean supportsCameraToggle = sensorPrivacyManager
        .supportsSensorToggle(Sensors.CAMERA);

Memeriksa perilaku aplikasi untuk merespons tombol beralih mikrofon dan kamera

Tombol mikrofon dan kamera tidak akan memengaruhi cara aplikasi menangani izin CAMERA dan RECORD_AUDIO, selama saat Anda mengikuti praktik terbaik untuk mendapatkan izin Android.

Secara khusus, pastikan aplikasi Anda melakukan hal-hal berikut:

Menunggu untuk mengakses kamera perangkat hingga pengguna memberikan izin CAMERA ke aplikasi Anda.
Menunggu untuk mengakses mikrofon perangkat hingga pengguna memberikan RECORD_AUDIO izin ke aplikasi Anda.

Indikator mikrofon dan kamera

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

Pada perangkat yang menjalankan Android 12, saat aplikasi mengakses mikrofon atau kamera, ikon akan muncul di status bar. Jika aplikasi berada dalam mode imersif, ikon akan muncul di pojok kanan atas layar. Pengguna dapat membuka Setelan Cepat dan memilih ikon untuk melihat aplikasi yang sedang menggunakan mikrofon atau kamera. Gambar 2 menunjukkan contoh screenshot yang berisi ikon.

Untuk memberikan pengalaman pengguna yang lebih baik, jangan mengakses mikrofon atau kamera hingga pengguna memberikan izin secara eksplisit ke aplikasi Anda.

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, SecurityException akan muncul.

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:

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 jendela TYPE_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. Pada Android 12, opasitas maksimum ini adalah 0,8. Nilai ini mungkin berubah pada rilis beta mendatang.

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 Pratinjau Developer 3 Android 12. 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

Visibilitas paket izin

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

Penerapan Bouncy Castle dihapus

Android 12 telah menghapus banyak implementasi BouncyCastle dari 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

Pada Android 12, saat aplikasi memanggil getPrimaryClip() untuk mengakses ClipData dari aplikasi yang berbeda untuk kali pertama, pesan toast akan memberi tahu pengguna tentang akses papan klip ini.

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

Pesan tidak muncul saat mengambil deskripsi klip

Aplikasi Anda mungkin memanggil getPrimaryClipDescription() untuk menerima informasi data saat ini yang ada di papan klip. Saat aplikasi Anda memanggil metode ini, sistem tidak akan menampilkan pesan toast.

Android 12 menyempurnakan metode ini untuk mendeteksi detail tambahan berikut:

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

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.

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 Update pembatasan antarmuka non-SDK di Android 12. Untuk mempelajari lebih lanjut tentang antarmuka non-SDK secara umum, baca Pembatasan antarmuka non-SDK.