Perubahan perilaku: Aplikasi yang menargetkan Android 16 atau yang lebih tinggi

Seperti rilis sebelumnya, Android 16 menyertakan perubahan perilaku yang mungkin memengaruhi aplikasi Anda. Perubahan perilaku berikut ini berlaku khusus bagi aplikasi yang menargetkan Android 16 atau yang lebih tinggi. Jika aplikasi Anda menargetkan Android 16 atau yang lebih tinggi, Anda harus memodifikasi aplikasi untuk mendukung perilaku ini, jika berlaku.

Pastikan Anda juga meninjau daftar perubahan perilaku yang memengaruhi semua aplikasi yang berjalan di Android 16, terlepas dari targetSdkVersion aplikasi Anda.

Pengalaman pengguna dan UI sistem

Android 16 (level API 36) menyertakan perubahan berikut yang dimaksudkan untuk menciptakan pengalaman pengguna yang lebih konsisten dan intuitif.

Opsi tidak menggunakan layar penuh akan dihapus

Android 15 menerapkan tampilan layar penuh untuk aplikasi yang menargetkan Android 15 (level API 35), tetapi aplikasi Anda dapat memilih untuk tidak menggunakan tampilan layar penuh dengan menyetel R.attr#windowOptOutEdgeToEdgeEnforcement ke true. Untuk aplikasi yang menargetkan Android 16 (level API 36), R.attr#windowOptOutEdgeToEdgeEnforcement tidak digunakan lagi dan dinonaktifkan, dan aplikasi Anda tidak dapat memilih untuk tidak ditampilkan di layar penuh.

• Jika aplikasi Anda menargetkan Android 16 (level API 36) dan berjalan di perangkat Android 15, R.attr#windowOptOutEdgeToEdgeEnforcement akan terus berfungsi.
• Jika aplikasi Anda menargetkan Android 16 (level API 36) dan berjalan di perangkat Android 16, R.attr#windowOptOutEdgeToEdgeEnforcement dinonaktifkan.

Untuk pengujian di Android 16, pastikan aplikasi Anda mendukung layar penuh dan hapus penggunaan R.attr#windowOptOutEdgeToEdgeEnforcement agar aplikasi Anda juga mendukung layar penuh di perangkat Android 15. Untuk mendukung tampilan layar penuh, lihat panduan Compose dan Tampilan.

Migrasi atau penonaktifan diperlukan untuk kembali prediktif

Untuk aplikasi yang menargetkan Android 16 (level API 36) atau yang lebih tinggi dan berjalan di perangkat Android 16 atau yang lebih tinggi, animasi sistem kembali prediktif (kembali ke layar utama, lintas tugas, dan lintas aktivitas) diaktifkan secara default. Selain itu, onBackPressed tidak dipanggil dan KeyEvent.KEYCODE_BACK tidak dikirim lagi.

Jika aplikasi Anda mencegat peristiwa kembali dan Anda belum bermigrasi ke kembali prediktif, update aplikasi Anda untuk menggunakan API navigasi kembali yang didukung, atau nonaktifkan sementara dengan menetapkan atribut android:enableOnBackInvokedCallback ke false dalam tag <application> atau <activity> pada file AndroidManifest.xml aplikasi Anda.

Animasi kembali ke layar utama prediktif.

Animasi lintas aktivitas prediktif.

Animasi lintas tugas prediktif.

API font elegan tidak digunakan lagi dan dinonaktifkan

Aplikasi yang menargetkan Android 15 (level API 35) memiliki atribut elegantTextHeight TextView yang ditetapkan ke true secara default, menggantikan font ringkas dengan font yang jauh lebih mudah dibaca. Anda dapat mengganti perilaku ini dengan menyetel atribut elegantTextHeight ke false.

Android 16 menghentikan penggunaan atribut elegantTextHeight, dan atribut akan diabaikan setelah aplikasi Anda menargetkan Android 16. "Font UI" yang dikontrol oleh API ini akan dihentikan, jadi Anda harus menyesuaikan tata letak apa pun untuk memastikan rendering teks yang konsisten dan siap untuk masa mendatang dalam bahasa Arab, Laos, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu, atau Thai.

Perilaku

elegantTextHeight untuk aplikasi yang menargetkan Android 14 (level API 34) dan yang lebih rendah, atau untuk aplikasi yang menargetkan Android 15 (level API 35) yang mengganti default dengan menyetel atribut elegantTextHeight ke false.

Perilaku

elegantTextHeight untuk aplikasi yang menargetkan Android 16 (level API 36), atau untuk aplikasi yang menargetkan Android 15 (level API 35) yang tidak mengganti default dengan menyetel atribut elegantTextHeight ke false.

Fungsi inti

Android 16 (level API 36) menyertakan perubahan berikut yang mengubah atau memperluas berbagai kemampuan inti sistem Android.

Pengoptimalan penjadwalan kerja tarif tetap

Sebelum menargetkan Android 16, saat scheduleAtFixedRate melewatkan eksekusi tugas karena berada di luar siklus proses yang valid, semua eksekusi yang terlewat akan segera dijalankan saat aplikasi kembali ke siklus proses yang valid.

Saat menargetkan Android 16, maksimal satu eksekusi yang terlewat dari scheduleAtFixedRate akan langsung dieksekusi saat aplikasi kembali ke siklus proses yang valid. Perubahan perilaku ini diharapkan dapat meningkatkan performa aplikasi. Uji perilaku ini di aplikasi Anda untuk memeriksa apakah aplikasi Anda terpengaruh. Anda juga dapat menguji dengan menggunakan framework kompatibilitas aplikasi dan mengaktifkan flag kompatibilitas STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS.

Faktor bentuk perangkat

Android 16 (level API 36) menyertakan perubahan berikut untuk aplikasi saat ditampilkan di perangkat layar besar.

Tata letak adaptif

Dengan aplikasi Android yang kini berjalan di berbagai perangkat (seperti ponsel, tablet, perangkat foldable, desktop, mobil, dan TV) dan mode tampilan jendela di layar besar (seperti tampilan layar terpisah dan mode jendela desktop), developer harus membuat aplikasi Android yang beradaptasi dengan ukuran layar dan jendela apa pun, terlepas dari orientasi perangkat. Paradigma seperti membatasi orientasi dan kemampuan mengubah ukuran terlalu ketat di dunia multiperangkat saat ini.

Mengabaikan batasan orientasi, kemampuan mengubah ukuran, dan rasio aspek

Untuk aplikasi yang menargetkan Android 16 (level API 36), batasan orientasi, kemampuan mengubah ukuran, dan rasio aspek tidak lagi berlaku pada layar dengan lebar terkecil >= 600 dp. Aplikasi mengisi seluruh jendela tampilan, terlepas dari rasio aspek atau orientasi pilihan pengguna, dan tidak menggunakan pillarboxing.

Perubahan ini memperkenalkan perilaku platform standar baru. Android beralih ke model yang mengharuskan aplikasi beradaptasi dengan berbagai orientasi, ukuran tampilan, dan rasio aspek. Batasan seperti orientasi tetap atau kemampuan mengubah ukuran yang terbatas menghambat kemampuan adaptasi aplikasi. Buat aplikasi Anda adaptif untuk memberikan pengalaman pengguna terbaik.

Anda juga dapat menguji perilaku ini dengan menggunakan framework kompatibilitas aplikasi dan mengaktifkan flag kompatibilitas UNIVERSAL_RESIZABLE_BY_DEFAULT.

Perubahan umum yang dapat menyebabkan gangguan

Mengabaikan batasan orientasi, pengubahan ukuran, dan rasio aspek dapat memengaruhi UI aplikasi Anda di beberapa perangkat, terutama elemen yang didesain untuk tata letak kecil yang terkunci dalam orientasi potret: misalnya, masalah seperti tata letak yang diregangkan dan animasi serta komponen di luar layar. Setiap asumsi tentang rasio aspek atau orientasi dapat menyebabkan masalah visual pada aplikasi Anda. Pelajari lebih lanjut cara menghindarinya dan meningkatkan perilaku adaptif aplikasi Anda.

Mengizinkan rotasi perangkat akan menghasilkan pembuatan ulang aktivitas yang lebih banyak, yang dapat mengakibatkan hilangnya status pengguna jika tidak dipertahankan dengan benar. Pelajari cara menyimpan status UI dengan benar di Menyimpan status UI.

Detail implementasi

Atribut manifes dan API runtime berikut diabaikan di seluruh perangkat layar besar dalam mode layar penuh dan multi-aplikasi:

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

Nilai berikut untuk screenOrientation, setRequestedOrientation(), dan getRequestedOrientation() diabaikan:

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

Terkait pengubahan ukuran tampilan, android:resizeableActivity="false", android:minAspectRatio, dan android:maxAspectRatio tidak akan berpengaruh.

Untuk aplikasi yang menargetkan Android 16 (level API 36), batasan orientasi, perubahan ukuran, dan rasio aspek aplikasi diabaikan di layar besar secara default. Setiap aplikasi yang belum sepenuhnya siap dapat mengganti perilaku ini untuk sementara dengan memilih tidak ikut, yang menghasilkan perilaku sebelumnya yaitu ditempatkan dalam mode kompatibilitas.

Pengecualian

Batasan orientasi, perubahan ukuran, dan rasio aspek Android 16 tidak berlaku dalam situasi berikut:

• Game (berdasarkan bendera android:appCategory)
• Pengguna secara eksplisit memilih untuk menggunakan perilaku default aplikasi dalam setelan rasio aspek perangkat
• Layar yang lebih kecil dari sw600dp

Menonaktifkan sementara

Untuk memilih tidak mengaktifkan aktivitas tertentu, deklarasikan properti manifes PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY:

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

Jika terlalu banyak bagian aplikasi Anda yang belum siap untuk Android 16, Anda dapat memilih untuk tidak ikut sepenuhnya dengan menerapkan properti yang sama di tingkat aplikasi:

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

Penting: Penonaktifan ini bersifat sementara dan tidak akan berlaku saat menargetkan level API 37 dalam rilis Android mendatang. Artinya, untuk aplikasi yang menargetkan API level 37, batasan orientasi, kemampuan mengubah ukuran, dan rasio aspek diabaikan pada layar yang setidaknya sw600dp.

Kesehatan dan kebugaran

Android 16 (level API 36) mencakup perubahan berikut terkait data kesehatan dan kebugaran.

Izin kesehatan dan kebugaran

Untuk aplikasi yang menargetkan Android 16 (API level 36) atau yang lebih tinggi, BODY_SENSORS izin menggunakan izin yang lebih terperinci di bagian android.permissions.health, yang Health Connect juga digunakan. Mulai Android 16, setiap API yang sebelumnya memerlukan BODY_SENSORS atau BODY_SENSORS_BACKGROUND kini memerlukan izin yang sesuai android.permissions.health. Hal ini memengaruhi jenis data, API, dan jenis layanan latar depan berikut:

• HEART_RATE_BPM dari Fitur Kesehatan di Wear OS
• Sensor.TYPE_HEART_RATE dari Android Sensor Manager
• heartRateAccuracy dan heartRateBpm dari ProtoLayout di Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH yang memerlukan izin android.permission.health masing-masing, bukan BODY_SENSORS

Jika aplikasi Anda menggunakan API ini, aplikasi tersebut harus meminta izin terperinci masing-masing:

• Untuk pemantauan Detak Jantung, SpO2, atau Suhu Kulit saat digunakan: minta izin terperinci di bagian android.permissions.health, seperti READ_HEART_RATE bukan BODY_SENSORS.
• Untuk akses sensor latar belakang: minta READ_HEALTH_DATA_IN_BACKGROUND, bukan BODY_SENSORS_BACKGROUND.

Izin ini sama dengan izin yang melindungi akses untuk membaca data dari Health Connect, datastore Android untuk data kesehatan, kebugaran, dan kesejahteraan.

Aplikasi seluler

Aplikasi seluler yang bermigrasi untuk menggunakan READ_HEART_RATE dan izin terperinci lainnya juga harus mendeklarasikan aktivitas untuk menampilkan kebijakan privasi aplikasi. Persyaratan ini sama dengan Health Connect.

Penting: Jika tidak memberikan alasan untuk aplikasi seluler, izin akan dicabut.

Konektivitas

Android 16 (level API 36) menyertakan perubahan berikut dalam stack Bluetooth untuk meningkatkan konektivitas dengan perangkat periferal.

Maksud baru untuk menangani hilangnya koneksi dan perubahan enkripsi

As part of the Improved bond loss handling, Android 16 also introduces 2 new intents to provide apps with greater awareness of bond loss and encryption changes.

Apps targeting Android 16 can now:

• Receive an ACTION_KEY_MISSING intent when remote bond loss is detected, allowing them to provide more informative user feedback and take appropriate actions.
• Receive an ACTION_ENCRYPTION_CHANGE intent whenever encryption status of the link changes. This includes encryption status change, encryption algorithm change, and encryption key size change. Apps must consider the bond restored if the link is successfully encrypted upon receiving ACTION_ENCRYPTION_CHANGE intent later.

Adapting to varying OEM implementations

While Android 16 introduces these new intents, their implementation and broadcasting can vary across different device manufacturers (OEMs). To ensure your app provides a consistent and reliable experience across all devices, developers should design their bond loss handling to gracefully adapt to these potential variations.

We recommend the following app behaviors:

• If the ACTION_KEY_MISSING intent is broadcast:

  The ACL (Asynchronous Connection-Less) link will be disconnected by the system, but the bond information for the device will be retained (as described here).

  Your app should use this intent as the primary signal for bond loss detection and guiding the user to confirm the remote device is in range before initiating device forgetting or re-pairing.

  If a device disconnects after ACTION_KEY_MISSING is received, your app should be cautious about reconnecting, as the device may no longer be bonded with the system.

• If the ACTION_KEY_MISSING intent is NOT broadcast:

  The ACL link will remain connected, and the bond information for the device will be removed by the system, same to behavior in Android 15.

  In this scenario, your app should continue its existing bond loss handling mechanisms as in previous Android releases, to detect and manage bond loss events.

Cara baru untuk menghapus koneksi bluetooth

Semua aplikasi yang menargetkan Android 16 kini dapat membatalkan penyambungan perangkat Bluetooth menggunakan API publik di CompanionDeviceManager. Jika perangkat pendamping dikelola sebagai pengaitan CDM, aplikasi dapat memicu penghapusan ikatan bluetooth menggunakan removeBond(int) API baru di perangkat terkait. Aplikasi dapat memantau perubahan status ikatan dengan memproses peristiwa siaran perangkat Bluetooth ACTION_BOND_STATE_CHANGED.

Keamanan

Android 16 (level API 36) menyertakan perubahan keamanan berikut.

Penguncian versi MediaStore

Untuk aplikasi yang menargetkan Android 16 atau yang lebih tinggi, MediaStore#getVersion() kini akan unik untuk setiap aplikasi. Hal ini menghilangkan properti identifikasi dari string versi untuk mencegah penyalahgunaan dan penggunaan untuk teknik sidik jari. Aplikasi tidak boleh membuat asumsi apa pun terkait format versi ini. Aplikasi seharusnya sudah menangani perubahan versi saat menggunakan API ini dan dalam sebagian besar kasus tidak perlu mengubah perilakunya saat ini, kecuali jika developer telah mencoba menyimpulkan informasi tambahan yang berada di luar cakupan API ini yang dimaksudkan.

Intent yang Lebih Aman

“更安全的 intent”功能是一项多阶段安全计划，旨在提高 Android 的 intent 解析机制的安全性。目标是在 intent 处理期间添加检查，并过滤不符合特定条件的 intent，从而保护应用免受恶意操作的侵害。

在 Android 15 中，该功能侧重于发送应用。现在，在 Android 16 中，控制权转移到了接收应用，开发者可以使用其应用清单选择启用严格的 intent 解析。

我们正在实施两项关键变更：

1. 显式 intent 必须与目标组件的 intent 过滤器匹配：如果 intent 显式定位到某个组件，则应与该组件的 intent 过滤器匹配。

2. 没有操作的 intent 无法匹配任何 intent 过滤器：未指定操作的 intent 不应解析为任何 intent 过滤器。

这些变更仅在涉及多个应用时适用，不会影响单个应用内的 intent 处理。

影响

选择启用性质意味着，开发者必须在应用清单中明确启用它，才能使其生效。 因此，此功能的影响将仅限于以下应用：

• 了解“更安全的 intent”功能及其优势。
• 主动选择在应用中采用更严格的 intent 处理实践。

这种选择性采用的方法可最大限度地降低破坏可能依赖于当前不太安全的 intent 解析行为的现有应用的风险。

虽然 Safer Intents 计划在 Android 16 中的初始影响可能有限，但其路线图表明，该计划将在未来的 Android 版本中产生更广泛的影响。我们计划最终将严格的意图解析设为默认行为。

通过使恶意应用更难利用 intent 解析机制中的漏洞，“更安全的 intent”功能有望显著提升 Android 生态系统的安全性。

不过，向选择停用和强制执行的过渡必须谨慎管理，以解决现有应用可能存在的兼容性问题。

实现

开发者需要在应用清单中使用 intentMatchingFlags 属性明确启用更严格的 intent 匹配。以下示例展示了如何为整个应用选择启用该功能，但在接收器上停用/选择停用该功能：

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

注意： 该属性也可以在 <application> 标记以及组件标记（例如 <activity>、<activity-alias>、<receiver>、<service>、<provider>）中指定，并且组件中的属性可用于替换 <application> 标记中的属性

有关支持的标志的更多信息：

标志名称	说明
enforceIntentFilter	对传入的 intent 强制执行更严格的匹配
无	针对传入 intent 停用所有特殊匹配规则。指定多个标志时，系统会优先考虑“无”标志，以解决值冲突问题
allowNullAction	放宽匹配规则，以允许匹配没有操作的 intent。此标志应与“enforceIntentFilter”结合使用，以实现特定行为

测试和调试

在强制执行处于有效状态时，如果 intent 调用方已正确填充 intent，应用应能正常运行。 不过，被屏蔽的 intent 会触发警告日志消息（例如 "Intent does not match component's intent filter:" 和 "Access blocked:"），并带有标记 "PackageManager."。这表示存在可能会影响应用的潜在问题，需要引起注意。

Logcat 过滤条件：

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

Pemfilteran syscall GPU

Untuk memperkuat platform GPU Mali, Mali GPU IOCTL yang tidak digunakan lagi atau ditujukan hanya untuk pengembangan GPU telah diblokir dalam build produksi. Selain itu, IOCTL yang digunakan untuk pembuatan profil GPU telah dibatasi untuk proses shell atau aplikasi yang dapat di-debug. Lihat update SAC untuk mengetahui detail selengkapnya tentang kebijakan tingkat platform.

Perubahan ini terjadi pada perangkat Pixel yang menggunakan GPU Mali (Pixel 6-9). Arm telah memberikan kategorisasi resmi IOCTL mereka di Documentation/ioctl-categories.rst dari rilis r54p2. Daftar ini akan terus dipertahankan dalam rilis driver mendatang.

Perubahan ini tidak memengaruhi API grafis yang didukung (termasuk Vulkan dan OpenGL), dan tidak diharapkan memengaruhi developer atau aplikasi yang ada. Alat pembuatan profil GPU seperti Streamline Performance Analyzer dan Android GPU Inspector tidak akan terpengaruh.

Pengujian

Jika Anda melihat penolakan SELinux yang mirip dengan berikut ini, kemungkinan aplikasi Anda terpengaruh oleh perubahan ini:

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

Jika aplikasi Anda perlu menggunakan IOCTL yang diblokir, laporkan bug dan tetapkan ke [e-mail].

FAQ

1. Apakah perubahan kebijakan ini berlaku untuk semua OEM? Perubahan ini akan bersifat opsional, tetapi tersedia untuk OEM mana pun yang ingin menggunakan metode penguatan ini. Petunjuk untuk menerapkan perubahan dapat ditemukan dalam dokumentasi penerapan.

2. Apakah wajib melakukan perubahan pada codebase OEM untuk menerapkan hal ini, atau apakah perubahan ini disertakan dengan rilis AOSP baru secara default? Perubahan tingkat platform akan disertakan dengan rilis AOSP baru secara default. Vendor dapat memilih untuk menerapkan perubahan ini dalam codebase mereka jika ingin menerapkannya.

3. Apakah SoC bertanggung jawab untuk terus memperbarui daftar IOCTL? Misalnya, jika perangkat saya menggunakan GPU ARM Mali, apakah saya perlu menghubungi ARM untuk mengetahui perubahan apa pun? Setiap SoC harus memperbarui daftar IOCTL per perangkat setelah rilis driver. Misalnya, ARM akan memperbarui daftar IOCTL yang dipublikasikan setelah update driver. Namun, OEM harus memastikan bahwa mereka menggabungkan update dalam SEPolicy, dan menambahkan IOCTL kustom yang dipilih ke daftar sesuai kebutuhan.

4. Apakah perubahan ini berlaku untuk semua perangkat Pixel yang dijual secara otomatis, atau apakah tindakan pengguna diperlukan untuk mengaktifkan sesuatu agar perubahan ini diterapkan? Perubahan ini berlaku untuk semua perangkat Pixel yang dijual menggunakan GPU Mali (Pixel 6-9). Tidak ada tindakan pengguna yang diperlukan untuk menerapkan perubahan ini.

5. Apakah penggunaan kebijakan ini akan memengaruhi performa driver kernel? Kebijakan ini diuji pada GPU Mali menggunakan GFXBench, dan tidak ada perubahan yang dapat diukur pada performa GPU.

6. Apakah daftar IOCTL harus selaras dengan versi driver kernel dan ruang pengguna saat ini? Ya, daftar IOCTL yang diizinkan harus disinkronkan dengan IOCTL yang didukung oleh driver kernel dan ruang pengguna. Jika IOCTL di ruang pengguna atau driver kernel diperbarui, daftar IOCTL SEPolicy harus diperbarui agar sesuai.

7. ARM telah mengategorikan IOCTL sebagai 'dibatasi'/'instrumentasi', tetapi kami ingin menggunakan beberapa di antaranya dalam kasus penggunaan produksi, dan/atau menolak yang lain. Setiap OEM/SoC bertanggung jawab untuk memutuskan cara mengategorikan IOCTL yang mereka gunakan, berdasarkan konfigurasi library Mali ruang pengguna mereka. Daftar ARM dapat digunakan untuk membantu memutuskan hal ini, tetapi kasus penggunaan setiap OEM/SoC mungkin berbeda.

Privasi

Android 16 (level API 36) menyertakan perubahan privasi berikut.

Izin Jaringan Lokal

Perangkat di LAN dapat diakses oleh aplikasi apa pun yang memiliki izin INTERNET. Hal ini memudahkan aplikasi terhubung ke perangkat lokal, tetapi juga memiliki implikasi privasi seperti membentuk sidik jari pengguna, dan menjadi proxy untuk lokasi.

Project Perlindungan Jaringan Lokal bertujuan melindungi privasi pengguna dengan membatasi akses ke jaringan lokal menggunakan izin runtime baru.

Rencana rilis

Perubahan ini akan di-deploy antara dua rilis, 25Q2 dan 26Q2 masing-masing. Developer harus mengikuti panduan ini untuk 25Q2 dan memberikan masukan karena perlindungan ini akan diterapkan pada rilis Android mendatang. Selain itu, mereka harus memperbarui skenario yang bergantung pada akses jaringan lokal implisit dengan menggunakan panduan berikut dan bersiap menghadapi penolakan dan pencabutan izin baru oleh pengguna.

Dampak

Pada tahap saat ini, LNP adalah fitur keikutsertaan yang berarti hanya aplikasi yang memilih untuk menggunakan fitur ini yang akan terpengaruh. Tujuan fase keikutsertaan adalah agar developer aplikasi memahami bagian aplikasi mereka yang bergantung pada akses jaringan lokal implisit sehingga mereka dapat bersiap untuk melindungi izinnya pada rilis berikutnya.

Aplikasi akan terpengaruh jika mengakses jaringan lokal pengguna menggunakan:

• Penggunaan soket mentah secara langsung atau library pada alamat jaringan lokal (misalnya, protokol penemuan layanan mDNS atau SSDP)
• Penggunaan class tingkat framework yang mengakses jaringan lokal (misalnya, NsdManager)

Traffic ke dan dari alamat jaringan lokal memerlukan izin akses jaringan lokal. Tabel berikut mencantumkan beberapa kasus umum:

Operasi Jaringan Tingkat Rendah Aplikasi	Izin Jaringan Lokal Diperlukan
Membuat koneksi TCP keluar	ya
Menerima koneksi TCP masuk	ya
Mengirim unicast, multicast, siaran UDP	ya
Menerima unicast, multicast, siaran UDP masuk	ya

Pembatasan ini diterapkan jauh di dalam stack jaringan, sehingga berlaku untuk semua API jaringan. Hal ini mencakup soket yang dibuat dalam kode native atau terkelola, library jaringan seperti Cronet dan OkHttp, serta API apa pun yang diimplementasikan di atasnya. Mencoba menyelesaikan layanan di jaringan lokal (yaitu, yang memiliki sufiks .local) akan memerlukan izin jaringan lokal.

Catatan: Traffic yang berasal dari Webview Android yang memerlukan akses jaringan lokal akan mewarisi status izin dari aplikasi host

Pengecualian untuk aturan di atas:

• Jika server DNS perangkat berada di jaringan lokal, traffic ke atau dari server tersebut (di port 53) tidak memerlukan izin akses jaringan lokal.
• Aplikasi yang menggunakan Output Switcher sebagai pemilih dalam aplikasi tidak memerlukan izin jaringan lokal (panduan lebih lanjut akan tersedia pada Kuartal 4 2025).

Catatan: Banyak skenario transmisi media bergantung pada akses ke jaringan lokal dan akan terpengaruh oleh perubahan ini. Namun, tidak semua aplikasi yang menawarkan transmisi perlu meminta izin baru. API dan panduan mendatang untuk menangani skenario transmisi akan diberikan pada Q4 2025.

Panduan Developer (Keikutsertaan)

Untuk mengaktifkan pembatasan jaringan lokal, lakukan langkah-langkah berikut:

1. Lakukan flash perangkat ke build dengan 25Q2 Beta 3 atau yang lebih baru.
2. Instal aplikasi yang akan diuji.

3. Alihkan flag Appcompat di adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Mulai Ulang Perangkat

Sekarang akses aplikasi Anda ke jaringan lokal dibatasi dan setiap upaya untuk mengakses jaringan lokal akan menyebabkan error soket. Jika Anda menggunakan API yang melakukan operasi jaringan lokal di luar proses aplikasi Anda (misalnya: NsdManager), API tersebut tidak akan terpengaruh selama fase keikutsertaan.

Untuk memulihkan akses, Anda harus memberikan izin aplikasi Anda untuk NEARBY_WIFI_DEVICES.

1. Pastikan aplikasi mendeklarasikan izin NEARBY_WIFI_DEVICES dalam manifesnya.
2. Buka Setelan > Aplikasi > [Nama Aplikasi] > Izin > Perangkat di sekitar > Izinkan.

Catatan: Dalam rilis Android mendatang, fitur ini akan dilindungi oleh izin baru dalam grup izin Perangkat di sekitar

Sekarang, akses aplikasi Anda ke jaringan lokal akan dipulihkan dan semua skenario Anda akan berfungsi seperti sebelum mengikutsertakan aplikasi.

Setelah penegakan perlindungan jaringan lokal dimulai, berikut dampak traffic jaringan aplikasi.

Izin	Permintaan LAN Keluar	Permintaan Internet Keluar/Masuk	Permintaan LAN Masuk
Diberikan	YouTube	YouTube	YouTube
Tidak Diberikan	Gagal	YouTube	Gagal

Gunakan perintah berikut untuk menonaktifkan flag App-Compat

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Error

Error yang timbul dari batasan ini akan dikembalikan ke soket panggilan setiap kali soket memanggil send atau varian send ke alamat jaringan lokal.

Contoh error:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Definisi Jaringan Lokal

Jaringan lokal dalam project ini mengacu pada jaringan IP yang menggunakan antarmuka jaringan yang mendukung siaran, seperti Wi-Fi atau Ethernet, tetapi tidak termasuk koneksi seluler (WWAN) atau VPN.

Berikut ini dianggap sebagai jaringan lokal:

IPv4:

• 169.254.0.0/16 // Link Lokal
• 100.64.0.0/10 // CGNAT
• 10.0.0.0/8 // RFC1918
• 172.16.0.0/12 // RFC1918
• 192.168.0.0/16 // RFC1918

IPv6:

• Link-local
• Rute yang terhubung langsung
• Jaringan stub seperti Thread
• Beberapa subnet (TBD)

Selain itu, alamat multicast (224.0.0.0/4, ff00::/8) dan alamat siaran IPv4 (255.255.255.255) diklasifikasikan sebagai alamat jaringan lokal.

Foto milik aplikasi

Saat diminta untuk memberikan izin foto dan video oleh aplikasi yang menargetkan SDK 36 atau yang lebih tinggi di perangkat yang menjalankan Android 16 atau yang lebih tinggi, pengguna yang memilih untuk membatasi akses ke media yang dipilih akan melihat foto apa pun yang dimiliki oleh aplikasi yang telah dipilih sebelumnya di pemilih foto. Pengguna dapat membatalkan pilihan salah satu item yang telah dipilih sebelumnya, yang akan mencabut akses aplikasi ke foto dan video tersebut.