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

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

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

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

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

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

اندروید ۱۵ برای برنامه‌هایی که اندروید ۱۵ (سطح API ۳۵) را هدف قرار می‌دهند، پشتیبانی از لبه به لبه را اجباری کرده است ، اما برنامه شما می‌تواند با تنظیم R.attr#windowOptOutEdgeToEdgeEnforcement روی true ، از این قابلیت انصراف دهد. برای برنامه‌هایی که اندروید ۱۶ (سطح API ۳۶) را هدف قرار می‌دهند، R.attr#windowOptOutEdgeToEdgeEnforcement منسوخ و غیرفعال شده است و برنامه شما نمی‌تواند از پشتیبانی از لبه به لبه انصراف دهد.

• اگر برنامه شما اندروید ۱۶ (سطح API ۳۶) را هدف قرار داده و روی دستگاهی با اندروید ۱۵ اجرا می‌شود، R.attr#windowOptOutEdgeToEdgeEnforcement به کار خود ادامه می‌دهد.
• اگر برنامه شما اندروید ۱۶ (سطح API ۳۶) را هدف قرار داده و روی دستگاهی با اندروید ۱۶ اجرا می‌شود، R.attr#windowOptOutEdgeToEdgeEnforcement غیرفعال است.

برای آزمایش در اندروید ۱۶، مطمئن شوید که برنامه شما از لبه به لبه پشتیبانی می‌کند و هرگونه استفاده از R.attr#windowOptOutEdgeToEdgeEnforcement را حذف کنید تا برنامه شما از لبه به لبه در دستگاه اندروید ۱۵ نیز پشتیبانی کند. برای پشتیبانی از لبه به لبه، به راهنمای نوشتن و نمایش‌ها مراجعه کنید.

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

برای برنامه‌هایی که اندروید ۱۶ (سطح API ۳۶) یا بالاتر را هدف قرار می‌دهند و روی دستگاه اندروید ۱۶ یا بالاتر اجرا می‌شوند، انیمیشن‌های سیستم بازگشت پیش‌بینی‌کننده (بازگشت به خانه، میان‌کاری و میان‌فعالیتی) به طور پیش‌فرض فعال هستند. علاوه بر این، onBackPressed فراخوانی نمی‌شود و KeyEvent.KEYCODE_BACK دیگر ارسال نمی‌شود.

اگر برنامه شما رویداد back را متوقف می‌کند و شما هنوز به حالت predictive back مهاجرت نکرده‌اید، برنامه خود را به‌روزرسانی کنید تا از APIهای پشتیبانی‌شده برای ناوبری back استفاده کند ، یا با تنظیم ویژگی android:enableOnBackInvokedCallback به false در تگ <application> یا <activity> از فایل AndroidManifest.xml برنامه خود، موقتاً از این حالت خارج شوید.

انیمیشن پیش‌بینی‌کننده‌ی بازگشت به خانه.

انیمیشن پیش‌بینی‌کننده‌ی فعالیت‌های متقاطع.

انیمیشن پیش‌بینی‌کننده‌ی وظایف متقابل.

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

برنامه‌هایی که Android 15 را هدف قرار می‌دهند (سطح API 35) دارای ویژگی elegantTextHeight TextView به‌طور پیش‌فرض روی true تنظیم شده‌اند و فونت فشرده را با فونتی که بسیار خواناتر است جایگزین می‌کند. می‌توانید با تنظیم ویژگی elegantTextHeight روی false این مورد را لغو کنید.

Android 16 ویژگی elegantTextHeight را منسوخ می‌کند، و زمانی که برنامه شما Android 16 را هدف قرار دهد، این ویژگی نادیده گرفته می‌شود. «فونت‌های UI» که توسط این APIها کنترل می‌شوند، متوقف می‌شوند، بنابراین باید هر گونه طرح‌بندی را برای اطمینان از ارائه متن ثابت و ثابت در آینده به زبان‌های عربی، لائوس، میانمار، تامیل، گجراتی، مالزی، تایلندی، تله‌آلو، کانا تطبیق دهید.

رفتار elegantTextHeight برای برنامه‌هایی که Android 14 (سطح API 34) و پایین‌تر را هدف قرار می‌دهند، یا برای برنامه‌هایی که Android 15 را هدف قرار می‌دهند (سطح API 35) که با تنظیم ویژگی elegantTextHeight روی false ، پیش‌فرض را لغو می‌کنند.

رفتار elegantTextHeight برای برنامه‌هایی که Android 16 را هدف قرار می‌دهند (سطح API 36)، یا برای برنامه‌هایی که Android 15 را هدف قرار می‌دهند (سطح API 35) که با تنظیم ویژگی elegantTextHeight روی false ، پیش‌فرض را لغو نکرده‌اند.

عملکرد اصلی

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

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

قبل از هدف قرار دادن اندروید 16، زمانی که scheduleAtFixedRate اجرای یک کار را به دلیل خارج از چرخه حیات فرآیند معتبر از دست داد، همه اجراهای از دست رفته بلافاصله با بازگشت برنامه به چرخه حیات معتبر اجرا می شوند.

هنگام هدف قرار دادن Android 16، حداکثر یک اجرای از دست رفته scheduleAtFixedRate بلافاصله پس از بازگشت برنامه به چرخه حیات معتبر اجرا می شود. انتظار می رود این تغییر رفتار باعث بهبود عملکرد برنامه شود. این رفتار را در برنامه خود آزمایش کنید تا بررسی کنید آیا برنامه شما تحت تأثیر قرار گرفته است یا خیر. همچنین می‌توانید با استفاده از چارچوب سازگاری برنامه و فعال کردن پرچم سازگار STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS آزمایش کنید.

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

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

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

با توجه به اینکه برنامه‌های اندروید اکنون روی دستگاه‌های متنوعی (مانند تلفن، تبلت، دستگاه‌های تاشو، کامپیوترهای رومیزی، ماشین و تلویزیون) اجرا می‌شوند و حالت‌های پنجره‌ای روی صفحه نمایش‌های بزرگ (مانند تقسیم صفحه و پنجره‌ای کردن دسکتاپ)، توسعه‌دهندگان باید برنامه‌های اندرویدی بسازند که صرف نظر از جهت‌گیری دستگاه، با هر صفحه و اندازه پنجره‌ای سازگار شوند. الگوهایی مانند محدود کردن جهت‌گیری و قابلیت تغییر اندازه در دنیای چنددستگاهی امروز بسیار محدودکننده هستند.

محدودیت‌های جهت‌گیری، تغییر اندازه و نسبت ابعاد را نادیده بگیرید

برای برنامه‌هایی که اندروید ۱۶ (سطح API ۳۶) را هدف قرار می‌دهند، محدودیت‌های جهت‌گیری، تغییر اندازه و نسبت ابعاد دیگر در نمایشگرهایی با کوچکترین عرض >= ۶۰۰dp اعمال نمی‌شوند. برنامه‌ها کل پنجره نمایشگر را صرف نظر از نسبت ابعاد یا جهت‌گیری ترجیحی کاربر پر می‌کنند و از ستون‌بندی استفاده نمی‌شود.

این تغییر، یک رفتار استاندارد جدید برای پلتفرم معرفی می‌کند. اندروید به سمت مدلی حرکت می‌کند که در آن انتظار می‌رود برنامه‌ها با جهت‌گیری‌ها، اندازه‌های نمایشگر و نسبت‌های ابعاد مختلف سازگار شوند. محدودیت‌هایی مانند جهت‌گیری ثابت یا قابلیت تغییر اندازه محدود، مانع از سازگاری برنامه می‌شود. برنامه خود را سازگار کنید تا بهترین تجربه کاربری ممکن را ارائه دهید.

همچنین می‌توانید این رفتار را با استفاده از چارچوب سازگاری برنامه و فعال کردن پرچم UNIVERSAL_RESIZABLE_BY_DEFAULT compat آزمایش کنید.

تغییرات رایج در شکستن قفل

نادیده گرفتن محدودیت‌های جهت‌گیری، تغییر اندازه و نسبت ابعاد ممکن است بر رابط کاربری برنامه شما در برخی دستگاه‌ها تأثیر بگذارد، به خصوص عناصری که برای طرح‌بندی‌های کوچک قفل‌شده در جهت عمودی طراحی شده‌اند: برای مثال، مسائلی مانند طرح‌بندی‌های کشیده و انیمیشن‌ها و اجزای خارج از صفحه. هرگونه فرض در مورد نسبت ابعاد یا جهت‌گیری می‌تواند باعث مشکلات بصری در برنامه شما شود. درباره نحوه اجتناب از آنها و بهبود رفتار تطبیقی ​​برنامه خود بیشتر بیاموزید .

فعال کردن چرخش دستگاه منجر به ایجاد مجدد فعالیت‌ها می‌شود که در صورت عدم حفظ صحیح، می‌تواند منجر به از دست رفتن وضعیت کاربر شود. نحوه ذخیره صحیح وضعیت رابط کاربری را در بخش «ذخیره وضعیت‌های رابط کاربری» بیاموزید.

جزئیات پیاده‌سازی

ویژگی‌های مانیفست و 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 هیچ تاثیری ندارند.

برای برنامه‌هایی که اندروید ۱۶ (سطح API ۳۶) را هدف قرار می‌دهند، محدودیت‌های جهت‌گیری برنامه، قابلیت تغییر اندازه و نسبت ابعاد به طور پیش‌فرض در صفحه نمایش‌های بزرگ نادیده گرفته می‌شوند، اما هر برنامه‌ای که کاملاً آماده نیست می‌تواند با انصراف (که منجر به رفتار قبلی قرار گرفتن در حالت سازگاری می‌شود) موقتاً این رفتار را نادیده بگیرد.

استثنائات

محدودیت‌های جهت‌گیری، تغییر اندازه و نسبت تصویر اندروید ۱۶ در شرایط زیر اعمال نمی‌شوند:

• بازی‌ها (بر اساس پرچم android:appCategory )
• کاربرانی که صریحاً رفتار پیش‌فرض برنامه را در تنظیمات نسبت ابعاد دستگاه انتخاب می‌کنند
• صفحه نمایش‌هایی که کوچکتر از sw600dp هستند

انصراف موقت

برای غیرفعال کردن یک فعالیت خاص، ویژگی manifest مربوط به PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY را اعلان کنید:

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

اگر بخش‌های زیادی از برنامه شما برای اندروید ۱۶ آماده نیستند، می‌توانید با اعمال همین ویژگی در سطح برنامه، به‌طور کامل از آن صرف‌نظر کنید:

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

مهم: این انصراف موقتی است و در نسخه‌های بعدی اندروید که API سطح ۳۷ را هدف قرار می‌دهند، اعمال نخواهد شد. یعنی، برای برنامه‌هایی که API سطح ۳۷ را هدف قرار می‌دهند، محدودیت‌های جهت‌گیری، تغییر اندازه و نسبت ابعاد در نمایشگرهایی که حداقل sw600dp هستند، نادیده گرفته می‌شوند.

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

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

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

For apps targeting Android 16 (API level 36) or higher, BODY_SENSORS permissions use more granular permissions under android.permissions.health, which Health Connect also uses. As of Android 16, any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND requires the corresponding android.permissions.health permission instead. This affects the following data types, APIs, and foreground service types:

• HEART_RATE_BPM from Health Services on Wear OS
• Sensor.TYPE_HEART_RATE from Android Sensor Manager
• heartRateAccuracy and heartRateBpm from ProtoLayout on Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH where the respective android.permission.health permission is needed in place of BODY_SENSORS

If your app uses these APIs, it should request the respective granular permissions:

• For while-in-use monitoring of Heart Rate, SpO2, or Skin Temperature: request the granular permission under android.permissions.health, such as READ_HEART_RATE instead of BODY_SENSORS.
• For background sensor access: request READ_HEALTH_DATA_IN_BACKGROUND instead of BODY_SENSORS_BACKGROUND.

These permissions are the same as those that guard access to reading data from Health Connect, the Android datastore for health, fitness, and wellness data.

Mobile apps

Mobile apps migrating to use the READ_HEART_RATE and other granular permissions must also declare an activity to display the app's privacy policy. This is the same requirement as Health Connect.

Important: Failure to provide the rationale for mobile apps will result in the permission being revoked.

اتصال

اندروید ۱۶ (سطح 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

برای برنامه‌هایی که اندروید 16 یا بالاتر را هدف قرار می‌دهند، MediaStore#getVersion() اکنون برای هر برنامه منحصر به فرد خواهد بود. این ویژگی های شناسایی را از رشته نسخه حذف می کند تا از سوء استفاده و استفاده از تکنیک های انگشت نگاری جلوگیری شود. برنامه ها نباید هیچ فرضی در مورد قالب این نسخه داشته باشند. برنامه‌ها از قبل باید هنگام استفاده از این API تغییرات نسخه را کنترل کنند و در بیشتر موارد نیازی به تغییر رفتار فعلی خود ندارند، مگر اینکه توسعه‌دهنده تلاش کرده باشد اطلاعات بیشتری را استنباط کند که فراتر از محدوده مورد نظر این API است.

مقاصد امن‌تر

The Safer Intents feature is a multi-phase security initiative designed to improve the security of Android's intent resolution mechanism. The goal is to protect apps from malicious actions by adding checks during intent processing and filtering intents that don't meet specific criteria.

In Android 15 the feature focused on the sending app, now with Android 16, shifts control to the receiving app, allowing developers to opt-in to strict intent resolution using their app manifest.

Two key changes are being implemented:

1. Explicit Intents Must Match the Target Component's Intent Filter: If an intent explicitly targets a component, it should match that component's intent filter.

2. Intents Without an Action Cannot Match any Intent Filter: Intents that don't have an action specified shouldn't be resolved to any intent filter.

These changes only apply when multiple apps are involved and don't affect intent handling within a single app.

Impact

The opt-in nature means that developers must explicitly enable it in their app manifest for it to take effect. As a result, the feature's impact will be limited to apps whose developers:

• Are aware of the Safer Intents feature and its benefits.
• Actively choose to incorporate stricter intent handling practices into their apps.

This opt-in approach minimizes the risk of breaking existing apps that may rely on the current less-secure intent resolution behavior.

While the initial impact in Android 16 may be limited, the Safer Intents initiative has a roadmap for broader impact in future Android releases. The plan is to eventually make strict intent resolution the default behavior.

The Safer Intents feature has the potential to significantly enhance the security of the Android ecosystem by making it more difficult for malicious apps to exploit vulnerabilities in the intent resolution mechanism.

However, the transition to opt-out and mandatory enforcement must be carefully managed to address potential compatibility issues with existing apps.

Implementation

Developers need to explicitly enable stricter intent matching using the intentMatchingFlags attribute in their app manifest. Here is an example where the feature is opt-in for the entire app, but disabled/opt-out on a receiver:

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

Note: The attribute can be specified on the <application> tag as well as at the component tags such as <activity>, <activity-alias>, <receiver>, <service>, <provider> and the attribute on the component can be used to override what's on the <application> tag

More on the supported flags:

Flag Name	Description
enforceIntentFilter	Enforces stricter matching for incoming intents
none	Disables all special matching rules for incoming intents. When specifying multiple flags, conflicting values are resolved by giving precedence to the "none" flag
allowNullAction	Relaxes the matching rules to allow intents without an action to match. This flag to be used in conjunction with "enforceIntentFilter" to achieve a specific behavior

Testing and Debugging

When the enforcement is active, apps should function correctly if the intent caller has properly populated the intent. However, blocked intents will trigger warning log messages like "Intent does not match component's intent filter:" and "Access blocked:" with the tag "PackageManager." This indicates a potential issue that could impact the app and requires attention.

Logcat filter:

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 [e-mail].

FAQ

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

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

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

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

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

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

7. 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 ارائه خواهد شد).

توجه: بسیاری از سناریوهای پخش رسانه‌ای به دسترسی به شبکه محلی بستگی دارند و تحت تأثیر این تغییر قرار خواهند گرفت. با این حال، همه برنامه‌هایی که پخش رسانه‌ای ارائه می‌دهند نیازی به درخواست مجوز جدید ندارند. APIها و راهنمایی‌های آینده برای مقابله با سناریوهای پخش رسانه‌ای در سه‌ماهه چهارم 25 ارائه خواهد شد.

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

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

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

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

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

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

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

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

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

توجه: در نسخه‌های بعدی اندروید، این ویژگی با مجوز جدیدی در گروه مجوزهای دستگاه‌های نزدیک محافظت خواهد شد.

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

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

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

برای غیرفعال کردن پرچم 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) به عنوان آدرس‌های شبکه محلی طبقه‌بندی می‌شوند.

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

{% شامل "/training/data-storage/shared/___posed-photos" %}