Halaman ini diterjemahkan oleh Cloud Translation API.

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

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.

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

`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) mencakup perubahan berikut yang mengubah atau memperluas berbagai kemampuan inti sistem Android.

Pengoptimalan penjadwalan kerja tarif tetap

Prior to targeting Android 16, when scheduleAtFixedRate missed a task execution due to being outside a valid process lifecycle, all missed executions immediately execute when the app returns to a valid lifecycle.

When targeting Android 16, at most one missed execution of scheduleAtFixedRate is immediately executed when the app returns to a valid lifecycle. This behavior change is expected to improve app performance. Test this behavior in your app to check if your app is impacted. You can also test by using the app compatibility framework and enabling the STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS compat flag.

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

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.

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

Sebagai bagian dari Peningkatan penanganan kehilangan ikatan, Android 16 juga memperkenalkan 2 intent baru untuk memberi aplikasi kesadaran yang lebih besar tentang kehilangan ikatan dan perubahan enkripsi.

Aplikasi yang menargetkan Android 16 kini dapat:

Menerima intent ACTION_KEY_MISSING saat kehilangan ikatan jarak jauh terdeteksi, sehingga memungkinkannya memberikan masukan pengguna yang lebih informatif dan mengambil tindakan yang sesuai.
Menerima intent ACTION_ENCRYPTION_CHANGE setiap kali status enkripsi link berubah. Hal ini mencakup perubahan status enkripsi, perubahan algoritma enkripsi, dan perubahan ukuran kunci enkripsi. Aplikasi harus mempertimbangkan pengikatan yang dipulihkan jika link berhasil dienkripsi setelah menerima intent ACTION_ENCRYPTION_CHANGE nanti.

Beradaptasi dengan berbagai implementasi OEM

Meskipun Android 16 memperkenalkan intent baru ini, penerapan dan siarannya dapat bervariasi di berbagai produsen perangkat (OEM). Untuk memastikan aplikasi Anda memberikan pengalaman yang konsisten dan andal di semua perangkat, developer harus mendesain penanganan kehilangan ikatan untuk beradaptasi dengan baik dengan potensi variasi ini.

Sebaiknya gunakan perilaku aplikasi berikut:

Jika intent ACTION_KEY_MISSING disiarkan:

Link ACL (Asynchronous Connection-Less) akan terputus oleh sistem, tetapi informasi ikatan untuk perangkat akan dipertahankan (seperti yang dijelaskan di sini).

Aplikasi Anda harus menggunakan intent ini sebagai sinyal utama untuk deteksi hilangnya ikatan dan memandu pengguna untuk mengonfirmasi bahwa perangkat jarak jauh berada dalam jangkauan sebelum memulai penghapusan perangkat atau penyambungan ulang.

Jika perangkat terputus setelah ACTION_KEY_MISSING diterima, aplikasi Anda harus berhati-hati saat menghubungkan kembali, karena perangkat mungkin tidak lagi terikat dengan sistem.
Jika intent ACTION_KEY_MISSING TIDAK disiarkan:

Link ACL akan tetap terhubung, dan informasi ikatan untuk perangkat akan dihapus oleh sistem, sama dengan perilaku di Android 15.

Dalam skenario ini, aplikasi Anda harus melanjutkan mekanisme penanganan hilangnya obligasi yang ada seperti pada rilis Android sebelumnya, untuk mendeteksi dan mengelola peristiwa hilangnya obligasi.

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

Intent Eksplisit Harus Cocok dengan Filter Intent Komponen Target: Jika intent secara eksplisit menargetkan komponen, intent tersebut harus cocok dengan filter intent komponen tersebut.
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>

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 android-partner-security@google.com.

FAQ

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

具有 INTERNET 权限的任何应用都可以访问局域网上的设备。这使得应用可以轻松连接到本地设备，但也存在隐私影响，例如形成用户指纹，以及成为位置信息的代理。

本地网络保护项目旨在通过在新的运行时权限后限制对本地网络的访问，来保护用户的隐私。

发布计划

此变更将分别在 25Q2 和 26Q2 这两个版本之间部署。开发者必须遵循 25Q2 的相关指南并分享反馈，因为这些保护措施将在后续 Android 版本中强制执行。此外，他们还需要按照以下指南更新依赖于隐式本地网络访问权限的场景，并为用户拒绝和撤消新权限做好准备。

影响

在当前阶段，LNP 是一项选择启用功能，这意味着只有选择启用的应用会受到影响。选择启用阶段的目标是让应用开发者了解应用的哪些部分依赖于隐式本地网络访问权限，以便他们可以为下一个版本做好权限保护准备。

如果应用使用以下方式访问用户的本地网络，则会受到影响：

在本地网络地址（例如 mDNS 或 SSDP 服务发现协议）上直接或通过库使用原始套接字
使用可访问本地网络的框架级类（例如 NsdManager）

向本地网络地址发送流量和从本地网络地址接收流量需要本地网络访问权限。下表列出了一些常见情况：

应用低级层网络操作	需要本地网络权限
建立出站 TCP 连接	是
接受传入的 TCP 连接	是
发送 UDP 单播、多播、广播	是
接收传入的 UDP 单播、多播、广播	是

这些限制是在网络堆栈深处实现的，因此适用于所有网络 API。这包括在原生代码或受管理代码中创建的套接字、Cronet 和 OkHttp 等网络库，以及基于这些库实现的任何 API。尝试解析本地网络上的服务（即带有 .local 后缀的服务）将需要本地网络权限。

上述规则的例外情况：

如果设备的 DNS 服务器位于本地网络上，则进出该服务器（位于端口 53）的流量不需要本地网络访问权限。
如果应用使用输出切换器作为其应用内选择器，则无需本地网络权限（更多指南将在 2025 年第 4 季度发布）。

开发者指南（选择启用）

如需选择启用本地网络限制，请执行以下操作：

将设备刷写到 25Q2 Beta 3 或更高版本的 build。
安装要测试的应用。

在 adb 中切换 Appcompat 标志：

adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

重启设备

现在，您的应用对本地网络的访问受到限制，任何访问本地网络的尝试都会导致套接字错误。如果您使用的 API 在应用进程之外执行本地网络操作（例如：NsdManager），在选择启用阶段，这些 API 不会受到影响。

如需恢复访问权限，您必须向应用授予 NEARBY_WIFI_DEVICES 权限。

确保应用在其清单中声明了 NEARBY_WIFI_DEVICES 权限。
依次前往设置 > 应用 > [应用名称] > 权限 > 附近的设备 > 允许。

现在，应用对本地网络的访问权限应该已恢复，并且所有场景都应像选择启用应用之前一样正常运行。

本地网络保护功能开始强制执行后，应用的网络流量将受到以下影响。

权限	出站 LAN 请求	出站/入站互联网请求	入站 LAN 请求
已授予	Works	Works	Works
未授予	最差排行榜	Works	最差排行榜

使用以下命令切换关闭应用兼容性标志

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

错误

每当调用套接字调用 send 或 send 变体向本地网络地址发送数据时，系统都会向该套接字返回因这些限制而产生的错误。

错误示例：

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

本地网络定义

此项目中的本地网络是指使用支持广播的网络接口（例如 Wi-Fi 或以太网）的 IP 网络，但不包括移动网络 (WWAN) 或 VPN 连接。

以下网络被视为本地网络：

IPv4：

169.254.0.0/16 // 链路本地
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：

链路本地
直接连接的路线
Thread 等桩网络
多个子网（待定）

此外，多播地址 (224.0.0.0/4、ff00::/8) 和 IPv4 广播地址 (255.255.255.255) 都归类为本地网络地址。

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.