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 强制实行全屏显示，但您的应用可以通过将 R.attr#windowOptOutEdgeToEdgeEnforcement 设置为 true 来选择停用。对于以 Android 16（API 级别 36）为目标平台的应用，R.attr#windowOptOutEdgeToEdgeEnforcement 已被废弃并停用，并且您的应用无法选择不采用从边缘到边缘的布局。

• 如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 15 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会继续正常运行。
• 如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 16 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会被停用。

如需在 Android 16 中进行测试，请确保您的应用支持无边框设计，并移除所有 R.attr#windowOptOutEdgeToEdgeEnforcement 用法，以便您的应用在 Android 15 设备上也能支持无边框设计。如需支持从边缘到边缘的显示，请参阅 Compose 和 Views 指南。

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

以 Android 15（API 级别 35）为目标平台的应用默认将 elegantTextHeight TextView 属性设置为 true，从而将紧凑型字体替换为可读性更高的字体。您可以通过将 elegantTextHeight 属性设置为 false 来替换此设置。

Android 16 弃用了 elegantTextHeight 属性，当您的应用以 Android 16 为目标平台后，系统会忽略该属性。由这些 API 控制的“界面字体”即将停用，因此您应调整所有布局，以确保阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语文本的呈现效果一致且不受未来变化的影响。

针对以 Android 14（API 级别 34）及更低版本为目标平台的应用，或针对以 Android 15（API 级别 35）为目标平台且通过将 elegantTextHeight 属性设置为 false 替换默认值的应用，

elegantTextHeight 行为。

以 Android 16（API 级别 36）为目标平台的应用，或以 Android 15（API 级别 35）为目标平台但未通过将 elegantTextHeight 属性设置为 false 来替换默认值的应用，其

elegantTextHeight 行为。

Fungsi inti

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

Pengoptimalan penjadwalan kerja tarif tetap

在以 Android 16 为目标平台之前，如果 scheduleAtFixedRate 因不在有效的进程生命周期内而错过了任务执行，则当应用返回到有效的生命周期时，所有错过的执行会立即执行。

以 Android 16 为目标平台时，当应用返回到有效的生命周期时，系统会立即执行最多 1 次未执行的 scheduleAtFixedRate 执行。此行为变更预计会提升应用性能。在您的应用中测试此行为，检查您的应用是否受到影响。您还可以使用应用兼容性框架并启用 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

现在，Android 应用可在各种设备（例如手机、平板电脑、可折叠设备、桌面设备、汽车和电视）上运行，并且在大屏设备上支持多种窗口模式（例如分屏和桌面窗口化模式），因此开发者应构建能够适应任何屏幕和窗口尺寸的 Android 应用，无论设备屏幕方向如何。在当今多设备的世界中，限制屏幕方向和尺寸可调整性等范式过于严格。

忽略屏幕方向、尺寸可调整性和宽高比限制

对于以 Android 16（API 级别 36）为目标平台的应用，在最小宽度 >= 600dp 的显示屏上，屏幕方向、尺寸调整能力和宽高比限制不再适用。应用会填满整个显示窗口，无论宽高比或用户偏好的屏幕方向如何，都不会使用竖屏黑边模式。

此变更引入了新的标准平台行为。Android 正在向一种模型转变，在该模型中，应用需要适应各种屏幕方向、显示大小和宽高比。固定屏幕方向或有限的尺寸调整等限制会阻碍应用的适应性。使应用具有自适应性，以提供尽可能最佳的用户体验。

您还可以使用应用兼容性框架并启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 兼容性标志来测试此行为。

常见的重大更改

忽略屏幕方向、可调整大小性和宽高比限制可能会影响应用在某些设备上的界面，尤其是那些专为锁定为纵向的小布局设计的元素：例如，布局拉伸、动画和组件超出屏幕等问题。任何关于宽高比或屏幕方向的假设都可能导致应用出现视觉问题。详细了解如何避免这些问题并改进应用的自适应行为。

允许设备旋转会导致更多 activity 重新创建，如果未正确保留用户状态，可能会导致用户状态丢失。如需了解如何正确保存界面状态，请参阅保存界面状态。

实现细节

在全屏模式和多窗口模式下，以下清单属性和运行时 API 会被大屏设备忽略：

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

系统会忽略 screenOrientation、setRequestedOrientation() 和 getRequestedOrientation() 的以下值：

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

对于显示屏可调整大小性，android:resizeableActivity="false"、android:minAspectRatio 和 android:maxAspectRatio 没有影响。

对于以 Android 16（API 级别 36）为目标平台的应用，默认情况下，大屏设备会忽略应用的屏幕方向、尺寸调整和宽高比限制。尚未完全准备就绪的每个应用都可以通过选择停用来暂时替换此行为，这会导致应用恢复到之前放置在兼容模式下的行为。

例外情况

在以下情况下，Android 16 的屏幕方向、尺寸调整能力和宽高比限制不适用：

• 游戏（基于 android:appCategory 标志）
• 用户在设备的宽高比设置中明确选择启用应用的默认行为
• 小于 sw600dp 的屏幕

暂时选择不接收

如需选择停用特定 activity，请声明 PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY 清单属性：

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

如果应用的很多部分尚未准备好支持 Android 16，您可以在应用级别应用相同的属性，从而完全选择不启用该功能：

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

重要提示： 此选择停用是临时性的，在未来的 Android 版本中，当目标 API 级别为 37 时，此选择停用将不再适用。也就是说，对于以 API 级别 37 为目标的应用，在至少为 sw600dp 的显示屏上，系统会忽略屏幕方向、尺寸可调整性和宽高比限制。

Kesehatan dan kebugaran

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

Izin kesehatan dan kebugaran

对于以 Android 16（API 级别 36）或更高版本为目标平台的应用， BODY_SENSORS 权限使用更精细的权限 under android.permissions.health，which Health Connect also uses。从 Android 16 开始，凡是以前需要具有 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 权限的 API，现在都需要获取相应的 android.permissions.health 权限。这会影响以下数据类型、API 和前台服务类型：

• HEART_RATE_BPM Wear OS 上的健康服务
• Sensor.TYPE_HEART_RATE 来自 Android Sensor Manager
• heartRateAccuracy 和 heartRateBpm（来自 Wear OS 上的 ProtoLayout）
• FOREGROUND_SERVICE_TYPE_HEALTH ，其中需要使用相应的 android.permission.health 权限来代替 BODY_SENSORS

如果您的应用使用这些 API，则应请求相应的精细权限：

• 如需在使用期间监测心率、血氧饱和度或体表温度： 请请求 android.permissions.health 下的精细权限，例如 READ_HEART_RATE，而不是 BODY_SENSORS。
• 如需访问后台传感器，请请求 READ_HEALTH_DATA_IN_BACKGROUND，而不是 BODY_SENSORS_BACKGROUND。

这些权限与保护对 Health Connect（用于存储健康、 健身和保健数据的 Android 数据存储区）中数据的读取访问权限的权限相同。

移动应用

迁移为使用 READ_HEART_RATE 和其他精细权限的移动应用还必须 声明一项 activity 以显示应用的隐私权政策。这与健康数据共享的要求相同。

**重要提示：** 如果未能为移动应用提供理由，系统将撤消相应 权限。

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

作为改进了对键值对丢失的处理的一部分，Android 16 还引入了 2 个新 intent，以便应用更好地了解键值对丢失和加密更改。

以 Android 16 为目标平台的应用现在可以：

• 在检测到远程键盘连接丢失时接收 ACTION_KEY_MISSING intent，以便提供更具信息量的用户反馈并采取适当的措施。
• 每当链接的加密状态发生变化时，都会收到 ACTION_ENCRYPTION_CHANGE intent。这包括加密状态更改、加密算法更改和加密密钥大小更改。如果应用在稍后收到 ACTION_ENCRYPTION_CHANGE intent 时成功加密了链接，则必须将该绑定视为已恢复。

适应不同的 OEM 实现

虽然 Android 16 引入了这些新 intent，但其实现和广播可能会因不同的设备制造商 (OEM) 而异。为了确保您的应用在所有设备上都能提供一致且可靠的体验，开发者应设计其绑定丢失处理机制，以妥善适应这些潜在的变化。

我们建议您采用以下应用行为：

• 如果广播 ACTION_KEY_MISSING intent：

  系统会断开 ACL（异步无连接）链接，但会保留设备的配对信息（如此处所述）。

  您的应用应将此 intent 用作检测配对丢失的主要信号，并在发起设备忘记或重新配对之前引导用户确认远程设备是否在范围内。

  如果设备在收到 ACTION_KEY_MISSING 后断开连接，您的应用应谨慎重新连接，因为设备可能已不再与系统绑定。

• 如果未广播 ACTION_KEY_MISSING intent：

  ACL 链接将保持连接状态，系统会移除设备的配对信息，与 Android 15 中的行为相同。

  在这种情况下，您的应用应继续使用与之前的 Android 版本相同的现有配对丢失处理机制，以检测和管理配对丢失事件。

Cara baru untuk menghapus koneksi bluetooth

现在，以 Android 16 为目标平台的所有应用都可以使用 CompanionDeviceManager 中的公共 API 解除蓝牙设备配对。如果配套设备作为 CDM 关联进行管理，则应用可以在关联的设备上使用新的 removeBond(int) API 触发蓝牙配对的移除。该应用可以通过监听蓝牙设备广播事件 ACTION_BOND_STATE_CHANGED 来监控配对状态变化。

Keamanan

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

Penguncian versi MediaStore

对于以 Android 16 或更高版本为目标平台的应用，MediaStore#getVersion() 现在将是每个应用的唯一标识。这会从版本字符串中移除标识属性，以防止滥用和用于指纹识别技术。应用不应对此版本的格式做出任何假设。在使用此 API 时，应用应已处理版本变更，并且在大多数情况下无需更改其当前行为，除非开发者尝试推断超出此 API 预期范围的其他信息。

Intent yang Lebih Aman

Fitur Safer Intents adalah inisiatif keamanan multi-fase yang dirancang untuk meningkatkan keamanan mekanisme resolusi intent Android. Tujuannya adalah melindungi aplikasi dari tindakan berbahaya dengan menambahkan pemeriksaan selama pemrosesan intent dan memfilter intent yang tidak memenuhi kriteria tertentu.

Di Android 15, fitur ini berfokus pada aplikasi pengirim. Sekarang, dengan Android 16, kontrol beralih ke aplikasi penerima, sehingga developer dapat memilih resolusi intent yang ketat menggunakan manifes aplikasi mereka.

Dua perubahan utama sedang diterapkan:

1. Intent Eksplisit Harus Cocok dengan Filter Intent Komponen Target: Jika intent secara eksplisit menargetkan komponen, intent tersebut harus cocok dengan filter intent komponen tersebut.

2. Intent Tanpa Tindakan Tidak Dapat Cocok dengan Filter Intent Apa Pun: Intent yang tidak memiliki tindakan yang ditentukan tidak boleh diselesaikan ke filter intent apa pun.

Perubahan ini hanya berlaku jika ada beberapa aplikasi yang terlibat dan tidak memengaruhi penanganan intent dalam satu aplikasi.

Dampak

Sifat opsional berarti developer harus mengaktifkannya secara eksplisit dalam manifes aplikasi agar dapat diterapkan. Akibatnya, dampak fitur ini akan terbatas pada aplikasi yang developernya:

• Mengetahui fitur Safer Intents dan manfaatnya.
• Secara aktif memilih untuk menggabungkan praktik penanganan intent yang lebih ketat ke dalam aplikasi mereka.

Pendekatan opsional ini meminimalkan risiko merusak aplikasi yang ada yang mungkin mengandalkan perilaku resolusi intent yang kurang aman saat ini.

Meskipun dampak awal di Android 16 mungkin terbatas, inisiatif Safer Intents memiliki peta rencana untuk dampak yang lebih luas dalam rilis Android mendatang. Rencananya adalah untuk akhirnya menjadikan resolusi intent yang ketat sebagai perilaku default.

Fitur Safer Intents berpotensi meningkatkan keamanan ekosistem Android secara signifikan dengan mempersulit aplikasi berbahaya untuk mengeksploitasi kerentanan dalam mekanisme resolusi intent.

Namun, transisi ke penonaktifan dan penerapan wajib harus dikelola dengan cermat untuk mengatasi potensi masalah kompatibilitas dengan aplikasi yang ada.

Penerapan

Developer harus mengaktifkan pencocokan intent yang lebih ketat secara eksplisit menggunakan atribut intentMatchingFlags dalam manifes aplikasi mereka. Berikut adalah contoh saat fitur ini bersifat opsional untuk seluruh aplikasi, tetapi dinonaktifkan/tidak diaktifkan di penerima:

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

Catatan: Atribut dapat ditentukan pada tag <application> serta pada tag komponen seperti <activity>, <activity-alias>, <receiver>, <service>, <provider> dan atribut pada komponen dapat digunakan untuk mengganti apa yang ada di tag <application>

Selengkapnya tentang flag yang didukung:

Nama Flag	Deskripsi
enforceIntentFilter	Menerapkan pencocokan yang lebih ketat untuk intent masuk
tidak ada	Menonaktifkan semua aturan pencocokan khusus untuk intent masuk. Saat menentukan beberapa flag, nilai yang bertentangan akan diselesaikan dengan memberikan prioritas ke flag "none"
allowNullAction	Melonggarkan aturan pencocokan untuk mengizinkan intent tanpa tindakan agar cocok. Flag ini akan digunakan bersama dengan "enforceIntentFilter" untuk mencapai perilaku tertentu

Pengujian dan Proses Debug

Saat penerapan aktif, aplikasi akan berfungsi dengan benar jika pemanggil intent telah mengisi intent dengan benar. Namun, intent yang diblokir akan memicu pesan log peringatan seperti "Intent does not match component's intent filter:" dan "Access blocked:" dengan tag "PackageManager." Hal ini menunjukkan potensi masalah yang dapat memengaruhi aplikasi dan memerlukan perhatian.

Filter 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

当面向 SDK 36 或更高版本的应用在搭载 Android 16 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。