این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

تغییرات رفتار: برنامه هایی که اندروید 16 یا بالاتر را هدف قرار می دهند

مانند نسخه‌های قبلی، اندروید ۱۶ شامل تغییرات رفتاری است که ممکن است بر برنامه شما تأثیر بگذارد. تغییرات رفتاری زیر منحصراً برای برنامه‌هایی اعمال می‌شود که اندروید ۱۶ یا بالاتر را هدف قرار می‌دهند. اگر برنامه شما اندروید ۱۶ یا بالاتر را هدف قرار می‌دهد، باید برنامه خود را برای پشتیبانی از این رفتارها، در صورت لزوم، اصلاح کنید.

حتماً فهرست تغییرات رفتاری که صرف نظر از targetSdkVersion برنامه شما، بر همه برنامه‌های در حال اجرا در اندروید ۱۶ تأثیر می‌گذارند را نیز بررسی کنید.

تجربه کاربری و رابط کاربری سیستم

اندروید ۱۶ (سطح API ۳۶) شامل تغییرات زیر است که برای ایجاد یک تجربه کاربری سازگارتر و شهودی‌تر در نظر گرفته شده‌اند.

کنار رفتن گزینه انصراف از لبه تا لبه

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 指南。

مهاجرت یا انصراف برای بازگشت پیش‌بینی‌کننده الزامی است

For apps targeting Android 16 (API level 36) or higher and running on an Android 16 or higher device, the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore.

If your app intercepts the back event and you haven't migrated to predictive back yet, update your app to use supported back navigation APIs, or temporarily opt out by setting the android:enableOnBackInvokedCallback attribute to false in the <application> or <activity> tag of your app's AndroidManifest.xml file.

The predictive back-to-home animation.

The predictive cross-activity animation.

The predictive cross-task animation.

APIهای فونت Elegant منسوخ و غیرفعال شدند

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

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

قابلیت‌های اصلی

اندروید ۱۶ (سطح API ۳۶) شامل تغییرات زیر است که قابلیت‌های اصلی مختلف سیستم اندروید را اصلاح یا گسترش می‌دهد.

بهینه‌سازی زمان‌بندی کار با نرخ ثابت

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

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

فاکتورهای شکل دستگاه

اندروید ۱۶ (سطح API ۳۶) شامل تغییرات زیر برای برنامه‌ها هنگام نمایش در دستگاه‌های صفحه نمایش بزرگ است.

طرح‌بندی‌های تطبیقی

现在，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>

سلامت و تناسب اندام

اندروید ۱۶ (سطح API ۳۶) شامل تغییرات زیر در رابطه با داده‌های سلامت و تناسب اندام است.

مجوزهای سلامت و تناسب اندام

对于以 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 以显示应用的隐私权政策。这与健康数据共享的要求相同。

اتصال

اندروید ۱۶ (سطح API ۳۶) شامل تغییرات زیر در پشته بلوتوث برای بهبود اتصال با دستگاه‌های جانبی است.

اهداف جدید برای مدیریت از دست دادن اوراق قرضه و تغییرات رمزگذاری

作为改进了对键值对丢失的处理的一部分，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 版本相同的现有配对丢失处理机制，以检测和管理配对丢失事件。

روش جدید برای حذف اتصال بلوتوث

همه برنامه‌هایی که اندروید 16 را هدف قرار می‌دهند، اکنون می‌توانند با استفاده از یک API عمومی در CompanionDeviceManager ، دستگاه‌های بلوتوث را لغو جفت کنند. اگر یک دستگاه همراه به عنوان یک انجمن CDM مدیریت می‌شود، برنامه می‌تواند با استفاده از API جدید removeBond(int) در دستگاه مرتبط، حذف پیوند بلوتوث را آغاز کند. این برنامه می‌تواند با گوش دادن به رویداد پخش دستگاه بلوتوث ACTION_BOND_STATE_CHANGED تغییرات وضعیت پیوند را کنترل کند.

امنیت

اندروید ۱۶ (سطح API ۳۶) شامل تغییرات امنیتی زیر است.

قفل شدن نسخه MediaStore

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

مقاصد امن‌تر

ویژگی Safer Intents یک ابتکار امنیتی چند مرحله‌ای است که برای بهبود امنیت مکانیسم تشخیص هدف اندروید طراحی شده است. هدف، محافظت از برنامه‌ها در برابر اقدامات مخرب با افزودن بررسی‌ها در طول پردازش هدف و فیلتر کردن اهدافی است که معیارهای خاصی را برآورده نمی‌کنند.

در اندروید ۱۵، این ویژگی که بر برنامه‌ی فرستنده متمرکز بود، اکنون در اندروید ۱۶، کنترل را به برنامه‌ی گیرنده منتقل می‌کند و به توسعه‌دهندگان اجازه می‌دهد تا با استفاده از مانیفست برنامه‌ی خود، وضوح دقیق هدف را انتخاب کنند.

دو تغییر اساسی در حال اجرا هستند:

اهداف صریح باید با فیلتر هدف کامپوننت هدف مطابقت داشته باشند: اگر یک هدف به صراحت یک کامپوننت را هدف قرار دهد، باید با فیلتر هدف آن کامپوننت مطابقت داشته باشد.
اینتنت‌های بدون اکشن نمی‌توانند با هیچ فیلتر اینتنتی مطابقت داشته باشند: اینتنت‌هایی که اکشن مشخصی ندارند، نباید با هیچ فیلتر اینتنتی تطبیق داده شوند.

این تغییرات فقط زمانی اعمال می‌شوند که چندین برنامه درگیر باشند و بر مدیریت قصد (intent handling) در یک برنامه واحد تأثیری ندارند.

تأثیر

ماهیت اختیاری آن به این معنی است که توسعه‌دهندگان باید آن را به صراحت در مانیفست برنامه خود فعال کنند تا فعال شود. در نتیجه، تأثیر این ویژگی محدود به برنامه‌هایی خواهد بود که توسعه‌دهندگان آنها:

از ویژگی Safer Intents و مزایای آن آگاه هستند.
فعالانه تصمیم می‌گیرند که شیوه‌های سختگیرانه‌تری را برای مدیریت قصد (intent handling) در برنامه‌های خود بگنجانند.

این رویکرد انتخابی، خطر از کار افتادن برنامه‌های موجود را که ممکن است به رفتار فعلیِ با امنیت کمتر برای حل اینتنت متکی باشند، به حداقل می‌رساند.

اگرچه ممکن است تأثیر اولیه در اندروید ۱۶ محدود باشد، اما ابتکار Safer Intents نقشه راهی برای تأثیر گسترده‌تر در نسخه‌های آینده اندروید دارد. این طرح در نهایت به این صورت است که تفکیک‌پذیری دقیق intent به رفتار پیش‌فرض تبدیل شود.

ویژگی Safer Intents این پتانسیل را دارد که با دشوارتر کردن سوءاستفاده از آسیب‌پذیری‌ها در مکانیسم تشخیص هدف (intent resolution)، امنیت اکوسیستم اندروید را به میزان قابل توجهی افزایش دهد.

با این حال، گذار به انصراف و اجرای اجباری باید با دقت مدیریت شود تا مشکلات سازگاری بالقوه با برنامه‌های موجود برطرف شود.

پیاده‌سازی

توسعه‌دهندگان باید با استفاده از ویژگی intentMatchingFlags در مانیفست برنامه خود، تطبیق دقیق‌تر اینتنت را به صراحت فعال کنند. در اینجا مثالی آورده شده است که در آن این ویژگی برای کل برنامه فعال است، اما در یک گیرنده غیرفعال/غیرفعال است:

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

اطلاعات بیشتر در مورد پرچم‌های پشتیبانی‌شده:

نام پرچم	توضیحات
فیلتر intent را اعمال کنید	تطبیق دقیق‌تری را برای اهداف ورودی اعمال می‌کند
هیچ کدام	تمام قوانین تطبیق ویژه را برای ورودی‌های ورودی غیرفعال می‌کند. هنگام تعیین چندین پرچم، مقادیر متناقض با اولویت دادن به پرچم "none" حل می‌شوند.
اجازه دادن به NullAction	قوانین تطبیق را آسان می‌کند تا به intent های بدون اکشن اجازه تطبیق داده شود. این پرچم همراه با "enforceIntentFilter" برای دستیابی به یک رفتار خاص استفاده می‌شود.

تست و اشکال‌زدایی

وقتی اجرای فعال باشد، اگر فراخواننده‌ی intent به درستی intent را پر کرده باشد، برنامه‌ها باید به درستی کار کنند. با این حال، intentهای مسدود شده پیام‌های هشداری مانند "Intent does not match component's intent filter:" و "Access blocked:" با برچسب "PackageManager." این نشان دهنده‌ی یک مشکل بالقوه است که می‌تواند بر برنامه تأثیر بگذارد و نیاز به توجه دارد.

فیلتر لاگ‌کت:

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

فیلتر کردن فراخوانی‌های سیستمی GPU

To harden the Mali GPU surface, Mali GPU IOCTLs that have been deprecated or are intended solely for GPU development have been blocked in production builds. Additionally, IOCTLs used for GPU profiling have been restricted to the shell process or debuggable applications. Refer to the SAC update for more details on the platform-level policy.

This change takes place on Pixel devices using the Mali GPU (Pixel 6-9). Arm has provided official categorization of their IOCTLs in Documentation/ioctl-categories.rst of their r54p2 release. This list will continue to be maintained in future driver releases.

This change does not impact supported graphics APIs (including Vulkan and OpenGL), and is not expected to impact developers or existing applications. GPU profiling tools such as the Streamline Performance Analyzer and the Android GPU Inspector won't be affected.

Testing

If you see a SELinux denial similar to the following, it is likely your application has been impacted by this change:

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

If your application needs to use blocked IOCTLs, please file a bug and assign it to android-partner-security@google.com.

FAQ

Does this policy change apply to all OEMs? This change will be opt-in, but available to any OEMs who would like to use this hardening method. Instructions for implementing the change can be found in the implementation documentation.
Is it mandatory to make changes in the OEM codebase to implement this, or does it come with a new AOSP release by default? The platform-level change will come with a new AOSP release by default. Vendors may opt-in to this change in their codebase if they would like to apply it.
Are SoCs responsible for keeping the IOCTL list up to date? For example, if my device uses an ARM Mali GPU, would I need to reach out to ARM for any of the changes? Individual SoCs must update their IOCTL lists per device upon driver release. For example, ARM will update their published IOCTL list upon driver updates. However, OEMs should make sure that they incorporate the updates in their SEPolicy, and add any selected custom IOCTLs to the lists as needed.
Does this change apply to all Pixel in-market devices automatically, or is a user action required to toggle something to apply this change? This change applies to all Pixel in-market devices using the Mali GPU (Pixel 6-9). No user action is required to apply this change.
Will use of this policy impact the performance of the kernel driver? This policy was tested on the Mali GPU using GFXBench, and no measurable change to GPU performance was observed.
Is it necessary for the IOCTL list to align with the current userspace and kernel driver versions? Yes, the list of allowed IOCTLs must be synchronized with the IOCTLs supported by both the userspace and kernel drivers. If the IOCTLs in the user space or kernel driver are updated, the SEPolicy IOCTL list must be updated to match.
ARM has categorized IOCTLs as 'restricted' / 'instrumentation', but we want to use some of them in production use-cases, and/or deny others. Individual OEMs/SoCs are responsible for deciding on how to categorize the IOCTLs they use, based on the configuration of their userspace Mali libraries. ARM's list can be used to help decide on these, but each OEM/SoC's use-case may be different.

حریم خصوصی

اندروید ۱۶ (سطح API ۳۶) شامل تغییرات حریم خصوصی زیر است.

مجوز شبکه محلی

دستگاه‌های موجود در شبکه محلی (LAN) می‌توانند توسط هر برنامه‌ای که مجوز INTERNET دارد، قابل دسترسی باشند. این امر اتصال برنامه‌ها به دستگاه‌های محلی را آسان می‌کند، اما پیامدهایی برای حریم خصوصی مانند تشکیل اثر انگشت کاربر و تبدیل شدن به یک پروکسی برای موقعیت مکانی نیز دارد.

پروژه حفاظت از شبکه‌های محلی (Local Network Protections) با هدف محافظت از حریم خصوصی کاربر، دسترسی به شبکه محلی را با مجوز زمان اجرا (runtime permission) جدیدی مسدود می‌کند.

طرح انتشار

این تغییر به ترتیب بین دو نسخه، سه‌ماهه دوم ۲۵ و سه‌ماهه دوم ۲۶، اعمال خواهد شد. ضروری است که توسعه‌دهندگان این راهنما را برای سه‌ماهه دوم ۲۵ دنبال کنند و بازخورد خود را به اشتراک بگذارند، زیرا این محافظت‌ها در نسخه بعدی اندروید اعمال خواهند شد . علاوه بر این، آن‌ها باید سناریوهایی را که به دسترسی ضمنی به شبکه محلی بستگی دارند، با استفاده از راهنمای زیر به‌روزرسانی کنند و برای رد کاربر و لغو مجوز جدید آماده شوند.

تأثیر

در مرحله فعلی، LNP یک ویژگی اختیاری است، به این معنی که فقط برنامه‌هایی که این ویژگی را انتخاب می‌کنند تحت تأثیر قرار می‌گیرند. هدف از مرحله اختیاری این است که توسعه‌دهندگان برنامه بفهمند کدام بخش‌های برنامه‌شان به دسترسی ضمنی به شبکه محلی نیاز دارد تا بتوانند برای انتشار بعدی، از آنها محافظت کنند.

اگر برنامه‌ها با استفاده از روش‌های زیر به شبکه محلی کاربر دسترسی پیدا کنند، تحت تأثیر قرار خواهند گرفت:

استفاده مستقیم یا کتابخانه‌ای از سوکت‌های خام روی آدرس‌های شبکه محلی (مثلاً mDNS یا پروتکل کشف سرویس SSDP)
استفاده از کلاس‌های سطح چارچوب که به شبکه محلی دسترسی دارند (مثلاً NsdManager)

ترافیک ورودی و خروجی از یک آدرس شبکه محلی نیاز به مجوز دسترسی به شبکه محلی دارد. جدول زیر برخی از موارد رایج را فهرست می‌کند:

عملیات شبکه سطح پایین برنامه	مجوز شبکه محلی مورد نیاز است
ایجاد یک اتصال TCP خروجی	بله
پذیرش اتصالات TCP ورودی	بله
ارسال UDP به صورت تک پخشی، چندپخشی، پخش همگانی	بله
دریافت یک UDP ورودی به صورت تک پخشی، چندپخشی، پخش همگانی	بله

این محدودیت‌ها در اعماق پشته شبکه پیاده‌سازی شده‌اند و بنابراین بر همه APIهای شبکه اعمال می‌شوند. این شامل سوکت‌های ایجاد شده با کد بومی یا مدیریت‌شده، کتابخانه‌های شبکه مانند Cronet و OkHttp و هر API پیاده‌سازی شده بر روی آن‌ها می‌شود. تلاش برای حل مشکلات سرویس‌ها در شبکه محلی (یعنی آن‌هایی که پسوند .local دارند) به مجوز شبکه محلی نیاز دارد.

استثنائات قوانین فوق:

اگر سرور DNS یک دستگاه در یک شبکه محلی باشد، ترافیک ورودی یا خروجی از آن (در پورت ۵۳) نیازی به مجوز دسترسی به شبکه محلی ندارد.
برنامه‌هایی که از Output Switcher به عنوان انتخابگر درون‌برنامه‌ای خود استفاده می‌کنند، به مجوزهای شبکه محلی نیاز نخواهند داشت (راهنمایی بیشتر در سه‌ماهه چهارم 2025 ارائه خواهد شد).

راهنمایی توسعه‌دهنده (انتخابی)

برای اعمال محدودیت‌های شبکه محلی، موارد زیر را انجام دهید:

دستگاه را به نسخه‌ای با نسخه بتا ۳ از ۲۵Q2 یا بالاتر فلش کنید.
برای تست، برنامه را نصب کنید.

تغییر وضعیت پرچم Appcompat در adb:

adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

دستگاه را ریبوت کنید

اکنون دسترسی برنامه شما به شبکه محلی محدود شده است و هرگونه تلاشی برای دسترسی به شبکه محلی منجر به خطاهای سوکت خواهد شد. اگر از APIهایی استفاده می‌کنید که عملیات شبکه محلی را خارج از فرآیند برنامه شما انجام می‌دهند (مثلاً: NsdManager)، در مرحله انتخاب، تحت تأثیر قرار نخواهند گرفت.

برای بازیابی دسترسی، باید به برنامه خود اجازه دسترسی به NEARBY_WIFI_DEVICES را بدهید.

مطمئن شوید که برنامه مجوز NEARBY_WIFI_DEVICES را در مانیفست خود اعلام کرده است.
به تنظیمات > برنامه‌ها > [نام برنامه] > مجوزها > دستگاه‌های نزدیک > مجاز بروید.

اکنون دسترسی برنامه شما به شبکه محلی باید بازیابی شده باشد و تمام سناریوهای شما باید مانند قبل از فعال کردن برنامه، کار کنند.

زمانی که اجرای قانون حفاظت از شبکه محلی آغاز شود، در اینجا نحوه تأثیر آن بر ترافیک شبکه برنامه آمده است.

اجازه	درخواست شبکه محلی خروجی	درخواست اینترنت خروجی/ورودی	درخواست شبکه محلی ورودی
اعطا شده	آثار	آثار	آثار
اعطا نشده	شکست‌ها	آثار	شکست‌ها

برای غیرفعال کردن پرچم App-Compat از دستور زیر استفاده کنید.

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

خطاها

خطاهای ناشی از این محدودیت‌ها، هر زمان که سوکت فراخوانی کننده، تابع send یا نوع دیگری از send را به یک آدرس شبکه محلی فراخوانی کند، به آن بازگردانده می‌شوند.

خطاهای مثال:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

تعریف شبکه محلی

منظور از شبکه محلی در این پروژه، شبکه‌ای مبتنی بر IP است که از یک رابط شبکه با قابلیت پخش همگانی، مانند Wi-Fi یا Ethernet، استفاده می‌کند، اما اتصالات تلفن همراه (WWAN) یا VPN را شامل نمی‌شود.

موارد زیر به عنوان شبکه‌های محلی در نظر گرفته می‌شوند:

آی‌پی‌وی۴:

۱۶۹.۲۵۴.۰.۰/۱۶ // لینک محلی
۱۰۰.۶۴.۰.۰/۱۰ // سی‌جی‌ان‌ای‌تی
۱۰.۰.۰.۰/۸ // RFC۱۹۱۸
۱۷۲.۱۶.۰.۰/۱۲ // RFC۱۹۱۸
‎192.168.0.0/16 // RFC1918‎

آی‌پی‌وی۶:

لینک-محلی
مسیرهای متصل مستقیم
شبکه‌های خرد مانند Thread
زیرشبکه‌های چندگانه (تاریخ انتشار نامشخص)

علاوه بر این، هر دو آدرس چندپخشی (224.0.0.0/4، ff00::/8) و آدرس پخش IPv4 (255.255.255.255) به عنوان آدرس‌های شبکه محلی طبقه‌بندی می‌شوند.

عکس‌های متعلق به برنامه

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

تغییرات رفتار: برنامه هایی که اندروید 16 یا بالاتر را هدف قرار می دهند با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

تجربه کاربری و رابط کاربری سیستم

کنار رفتن گزینه انصراف از لبه تا لبه

مهاجرت یا انصراف برای بازگشت پیش‌بینی‌کننده الزامی است

APIهای فونت Elegant منسوخ و غیرفعال شدند

قابلیت‌های اصلی

بهینه‌سازی زمان‌بندی کار با نرخ ثابت

فاکتورهای شکل دستگاه

طرح‌بندی‌های تطبیقی

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

常见的重大更改

实现细节

例外情况

暂时选择不接收

سلامت و تناسب اندام

مجوزهای سلامت و تناسب اندام

移动应用

اتصال

اهداف جدید برای مدیریت از دست دادن اوراق قرضه و تغییرات رمزگذاری

适应不同的 OEM 实现

روش جدید برای حذف اتصال بلوتوث

امنیت

قفل شدن نسخه MediaStore

مقاصد امن‌تر

تأثیر

پیاده‌سازی

تست و اشکال‌زدایی

فیلتر کردن فراخوانی‌های سیستمی GPU

Testing

FAQ

حریم خصوصی

مجوز شبکه محلی

طرح انتشار

تأثیر

راهنمایی توسعه‌دهنده (انتخابی)

خطاها

تعریف شبکه محلی

عکس‌های متعلق به برنامه

تغییرات رفتار: برنامه هایی که اندروید 16 یا بالاتر را هدف قرار می دهند