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.

Penghapusan opsi tidak menggunakan layar penuh

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

对于以 Android 16（API 级别 36）或更高版本为目标平台且在搭载 Android 16 或更高版本的设备上运行的应用，预测性返回系统动画（返回主屏幕、跨任务和跨 activity）默认处于启用状态。此外，系统不再调用 onBackPressed，也不再调度 KeyEvent.KEYCODE_BACK。

如果您的应用会拦截返回事件，但您尚未迁移到预测性返回，请更新应用以使用受支持的返回导航 API，或者通过在应用的 AndroidManifest.xml 文件的 <application> 或 <activity> 标记中将 android:enableOnBackInvokedCallback 属性设置为 false 来暂时选择停用。

预测性返回首页动画。

预测性跨 activity 动画。

预测性跨任务动画。

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

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

• HEART_RATE_BPM dari Layanan Kesehatan di Wear OS
• Sensor.TYPE_HEART_RATE dari Android Sensor Manager
• heartRateAccuracy dan heartRateBpm dari ProtoLayout di Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH jika izin android.permission.health yang sesuai diperlukan sebagai pengganti BODY_SENSORS

Jika aplikasi Anda menggunakan API ini, aplikasi tersebut harus meminta izin terperinci yang sesuai:

• Untuk pemantauan Detak Jantung, SpO2, atau Suhu Kulit saat digunakan: minta izin terperinci di 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, penyimpanan data Android untuk data kesehatan, kebugaran, dan kebugaran.

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 Anda 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 perubahan enkripsi dan hilangnya koneksi

作为改进了对键值对丢失的处理的一部分，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) menghadirkan 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

Fitur Safer Intents adalah inisiatif keamanan multi-fase yang dirancang untuk meningkatkan keamanan mekanisme penyelesaian intent Android. Tujuannya adalah untuk 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, kini dengan Android 16, kontrol dialihkan ke aplikasi penerima, sehingga developer dapat memilih untuk menggunakan 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

Karena bersifat keikutsertaan, developer harus mengaktifkannya secara eksplisit di manifes aplikasi agar dapat diterapkan. Akibatnya, dampak fitur ini akan terbatas pada aplikasi yang developernya:

• Mengetahui fitur Maksud Lebih Aman dan manfaatnya.
• Secara aktif memilih untuk menerapkan praktik penanganan maksud yang lebih ketat ke dalam aplikasi mereka.

Pendekatan keikutsertaan ini meminimalkan risiko merusak aplikasi yang ada yang mungkin mengandalkan perilaku penyelesaian maksud yang kurang aman saat ini.

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

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

Namun, transisi ke penegakan wajib dan penegakan yang memungkinkan pengguna memilih untuk tidak ikut harus dikelola dengan cermat untuk mengatasi potensi masalah kompatibilitas dengan aplikasi yang ada.

Implementasi

Developer harus mengaktifkan pencocokan intent yang lebih ketat secara eksplisit menggunakan atribut intentMatchingFlags dalam manifes aplikasi mereka. Berikut adalah contoh saat fitur diaktifkan 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 juga dapat ditentukan pada tag <application> serta pada tag komponen seperti <activity>, <activity-alias>, <receiver>, <service>, <provider>, dan atribut pada komponen dapat digunakan untuk menggantikan atribut pada tag <application>

Selengkapnya tentang tanda yang didukung:

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

Pengujian dan Proses Debug

Saat penegakan aktif, aplikasi harus berfungsi dengan benar jika pemanggil intent telah mengisi intent dengan benar. Namun, maksud 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, IOCTL GPU Mali yang telah dihentikan 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 pembaruan SAC untuk mengetahui detail selengkapnya tentang kebijakan tingkat platform.

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

Perubahan ini tidak memengaruhi API grafis yang didukung (termasuk Vulkan dan OpenGL), dan diperkirakan tidak akan 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 telah 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 bug tersebut ke [e-mail].

FAQ

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

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

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

4. Apakah perubahan ini diterapkan secara otomatis ke semua perangkat Pixel yang tersedia di pasar, atau apakah tindakan pengguna diperlukan untuk mengaktifkan sesuatu agar perubahan ini diterapkan? Perubahan ini berlaku untuk semua perangkat Pixel yang tersedia di pasar yang menggunakan GPU Mali (Pixel 6-9). Pengguna tidak perlu melakukan tindakan apa pun untuk menerapkan perubahan ini.

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

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

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

Privasi

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

Izin Jaringan Lokal

Devices on the LAN can be accessed by any app that has the INTERNET permission. This makes it easy for apps to connect to local devices but it also has privacy implications such as forming a fingerprint of the user, and being a proxy for location.

The Local Network Protections project aims to protect the user's privacy by gating access to the local network behind a new runtime permission.

Release plan

This change will be deployed between two releases, 25Q2 and 26Q2 respectively. It is imperative that developers follow this guidance for 25Q2 and share feedback because these protections will be enforced at a later Android release. Moreover, they will need to update scenarios which depend on implicit local network access by using the following guidance and prepare for user rejection and revocation of the new permission.

Impact

At the current stage, LNP is an opt-in feature which means only the apps that opt in will be affected. The goal of the opt-in phase is for app developers to understand which parts of their app depend on implicit local network access such that they can prepare to permission guard them for the next release.

Apps will be affected if they access the user's local network using:

• Direct or library use of raw sockets on local network addresses (e.g. mDNS or SSDP service discovery protocol)
• Use of framework level classes that access the local network (e.g. NsdManager)

Traffic to and from a local network address requires local network access permission. The following table lists some common cases:

App Low Level Network Operation	Local Network Permission Required
Making an outgoing TCP connection	yes
Accepting incoming TCP connections	yes
Sending a UDP unicast, multicast, broadcast	yes
Receiving an incoming UDP unicast, multicast, broadcast	yes

These restrictions are implemented deep in the networking stack, and thus they apply to all networking APIs. This includes sockets created in native or managed code, networking libraries like Cronet and OkHttp, and any APIs implemented on top of those. Trying to resolve services on the local network (i.e. those with a .local suffix) will require local network permission.

Note: Traffic originating from Android Webviews that require local network access will inherit permission state from the host app

Exceptions to the rules above:

• If a device's DNS server is on a local network, traffic to or from it (at port 53) doesn't require local network access permission.
• Applications using Output Switcher as their in-app picker won't need local network permissions (more guidance to come in 2025Q4).

Note: Many media casting scenarios depend on access to the local network and will be impacted by this change. However, not all apps which offer casting will need to request the new permission. Future APIs and guidance for dealing with casting scenarios will be provided in 25Q4.

Developer Guidance (Opt-in)

To opt into local network restrictions, do the following:

1. Flash the device to a build with 25Q2 Beta 3 or later.
2. Install the app to be tested.

3. Toggle the Appcompat flag in adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reboot The device

Now your app's access to the local network is restricted and any attempt to access the local network will lead to socket errors. If you are using APIs that perform local network operations outside of your app process (ex: NsdManager), they won't be impacted during the opt-in phase.

To restore access, you must grant your app permission to NEARBY_WIFI_DEVICES.

1. Ensure the app declares the NEARBY_WIFI_DEVICES permission in its manifest.
2. Go to Settings > Apps > [Application Name] > Permissions > Nearby devices > Allow.

Note: In a future Android release, this feature will be guarded by a new permission in the Nearby devices permission group

Now your app's access to the local network should be restored and all your scenarios should work as they did prior to opting the app in.

Once enforcement for local network protection begins, here is how the app network traffic will be impacted.

Permission	Outbound LAN Request	Outbound/Inbound Internet Request	Inbound LAN Request
Granted	Works	Works	Works
Not Granted	Fails	Works	Fails

Use the following command to toggle-off the App-Compat flag

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errors

Errors arising from these restrictions will be returned to the calling socket whenever it invokes send or a send variant to a local network address.

Example errors:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Local Network Definition

A local network in this project refers to an IP network that utilizes a broadcast-capable network interface, such as Wi-Fi or Ethernet, but excludes cellular (WWAN) or VPN connections.

The following are considered local networks:

IPv4:

• 169.254.0.0/16 // Link Local
• 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
• Directly-connected routes
• Stub networks like Thread
• Multiple-subnets (TBD)

Additionally, both multicast addresses (224.0.0.0/4, ff00::/8) and the IPv4 broadcast address (255.255.255.255) are classified as local network addresses.

Foto milik aplikasi

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