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

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

حتماً فهرستی از تغییرات رفتاری را نیز مرور کنید که بر همه برنامه‌های در حال اجرا در Android 16 بدون توجه به targetSdkVersion برنامه شما تأثیر می‌گذارد.

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

Android 16 (سطح API 36) شامل تغییرات زیر است که برای ایجاد یک تجربه کاربری سازگارتر و بصری در نظر گرفته شده است.

انصراف لبه به لبه حذف می شود

Android 15 برای برنامه‌هایی که Android 15 را هدف قرار می‌دهند (سطح API 35) لبه به لبه اعمال می‌شود ، اما برنامه شما می‌تواند با تنظیم 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 نیز پشتیبانی کند. برای پشتیبانی از لبه به لبه، به راهنمای نوشتن و مشاهده مراجعه کنید.

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

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

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

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

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

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

عملکرد اصلی

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

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

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

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

عوامل شکل دستگاه

Android 16 (سطح API 36) شامل تغییرات زیر برای برنامه‌ها هنگام نمایش در دستگاه‌های صفحه بزرگ است.

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

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

جهت گیری، قابلیت تغییر اندازه و محدودیت های نسبت تصویر را نادیده بگیرید

برای برنامه‌هایی که Android 16 (سطح API 36) را هدف قرار می‌دهند، Android 16 شامل تغییراتی در نحوه مدیریت سیستم جهت‌گیری، قابلیت تغییر اندازه و محدودیت‌های نسبت ابعاد است. در نمایشگرهایی با کمترین عرض >= 600dp، محدودیت ها دیگر اعمال نمی شوند. برنامه‌ها همچنین کل پنجره نمایشگر را بدون توجه به نسبت ابعاد یا جهت‌گیری ترجیحی کاربر پر می‌کنند و از ستون‌باکسینگ استفاده نمی‌شود.

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

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

تغییرات متداول شکستن

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

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

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

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

به طور موقت انصراف دهید

برای انصراف از یک فعالیت خاص، ویژگی 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>

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

اندروید 16 (سطح API 36) شامل تغییرات زیر مربوط به داده های سلامت و تناسب اندام است.

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

برای برنامه‌هایی که Android 16 (سطح API 36) یا بالاتر را هدف قرار می‌دهند، مجوزهای BODY_SENSORS از مجوزهای دقیق‌تری در android.permissions.health استفاده می‌کنند که Health Connect نیز از آن استفاده می‌کند. از Android 16، هر API که قبلاً به BODY_SENSORS یا BODY_SENSORS_BACKGROUND نیاز داشت، در عوض به مجوز android.permissions.health مربوطه نیاز دارد. این بر انواع داده‌ها، APIها و انواع خدمات پیش‌زمینه زیر تأثیر می‌گذارد:

• HEART_RATE_BPM از Health Services on Wear OS
• Sensor.TYPE_HEART_RATE از Android Sensor Manager
• heartRateAccuracy و heartRateBpm از ProtoLayout در Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH که در آن مجوز android.permission.health مربوطه به جای BODY_SENSORS مورد نیاز است

اگر برنامه شما از این APIها استفاده می‌کند، باید مجوزهای دقیق مربوطه را درخواست کند:

• برای نظارت بر ضربان قلب، SpO2 یا دمای پوست در حین استفاده: به جای BODY_SENSORS ، مجوز دانه‌بندی را در android.permissions.health درخواست کنید، مانند READ_HEART_RATE .
• برای دسترسی به حسگر پس‌زمینه: به جای BODY_SENSORS_BACKGROUND READ_HEALTH_DATA_IN_BACKGROUND درخواست کنید.

این مجوزها همان مجوزهایی هستند که از دسترسی به داده‌های خواندن از Health Connect ، ذخیره‌گاه داده Android برای داده‌های سلامتی، تناسب اندام و سلامتی محافظت می‌کنند.

برنامه های موبایل

برنامه‌های موبایلی که برای استفاده از READ_HEART_RATE و سایر مجوزهای جزئی مهاجرت می‌کنند، باید فعالیتی را برای نمایش خط‌مشی رازداری برنامه اعلام کنند . این همان نیاز Health Connect است.

قابلیت اتصال

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

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

به عنوان بخشی از بهبود مدیریت از دست دادن اوراق قرضه ، اندروید 16 همچنین 2 هدف جدید را معرفی می کند تا برنامه ها را با آگاهی بیشتر از از دست دادن اوراق قرضه و تغییرات رمزگذاری ارائه کند.

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

• هنگامی که از دست دادن اوراق قرضه از راه دور شناسایی شد، یک هدف ACTION_KEY_MISSING دریافت کنید، که به آنها امکان می دهد بازخورد آموزنده تری از کاربر ارائه دهند و اقدامات مناسب را انجام دهند.
• هر زمان که وضعیت رمزگذاری پیوند تغییر کرد، یک هدف ACTION_ENCRYPTION_CHANGE دریافت کنید. این شامل تغییر وضعیت رمزگذاری، تغییر الگوریتم رمزگذاری و تغییر اندازه کلید رمزگذاری است. اگر بعداً پس از دریافت هدف ACTION_ENCRYPTION_CHANGE پیوند با موفقیت رمزگذاری شد، برنامه‌ها باید پیوند را بازیابی شده در نظر بگیرند.

انطباق با پیاده سازی های مختلف OEM

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

ما رفتارهای برنامه زیر را توصیه می کنیم:

• اگر هدف ACTION_KEY_MISSING پخش شود:

  پیوند ACL (اتصال ناهمگام-کمتر) توسط سیستم قطع خواهد شد، اما اطلاعات پیوند دستگاه حفظ خواهد شد (همانطور که در اینجا توضیح داده شده است).

  برنامه شما باید از این هدف به‌عنوان سیگنال اصلی برای تشخیص از دست دادن اوراق قرضه استفاده کند و کاربر را راهنمایی کند تا قبل از شروع فراموشی یا جفت‌سازی مجدد دستگاه تأیید کند که دستگاه راه دور در محدوده است.

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

• اگر هدف ACTION_KEY_MISSING پخش نشد:

  پیوند ACL متصل باقی می‌ماند، و اطلاعات پیوند دستگاه توسط سیستم حذف می‌شود، مانند رفتار در Android 15.

  در این سناریو، برنامه شما باید به مکانیسم‌های مدیریت از دست دادن اوراق قرضه موجود خود مانند نسخه‌های قبلی اندروید ادامه دهد تا رویدادهای از دست دادن اوراق قرضه را شناسایی و مدیریت کند.

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

All apps targeting Android 16 are now able to unpair bluetooth devices using a public API in CompanionDeviceManager. If a companion device is being managed as a CDM association, then the app can trigger bluetooth bond removal by using the new removeBond(int) API on the associated device. The app can monitor the bond state changes by listening to the bluetooth device broadcast event ACTION_BOND_STATE_CHANGED.

امنیت

اندروید 16 (سطح API 36) شامل تغییرات امنیتی زیر است.

قفل شدن نسخه MediaStore

For apps targeting Android 16 or higher, MediaStore#getVersion() will now be unique to each app. This eliminates identifying properties from the version string to prevent abuse and usage for fingerprinting techniques. Apps shouldn't make any assumptions around the format of this version. Apps should already handle version changes when using this API and in most cases shouldn't need to change their current behavior, unless the developer has attempted to infer additional information that is beyond the intended scope of this API.

مقاصد امن تر

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

در اندروید 15، این ویژگی با تمرکز بر برنامه ارسال، اکنون با اندروید 16، کنترل را به برنامه دریافت کننده منتقل می کند و به توسعه دهندگان این امکان را می دهد تا با استفاده از مانیفست برنامه خود، رزولوشن دقیق هدف را انتخاب کنند.

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

1. مقاصد صریح باید با فیلتر هدف مؤلفه هدف مطابقت داشته باشد: اگر هدفی به صراحت یک مؤلفه را هدف قرار دهد، باید با فیلتر هدف آن مؤلفه مطابقت داشته باشد.

2. Intents Without Action نمی تواند با هیچ فیلتر Intent مطابقت داشته باشد: مقاصدی که عملکرد مشخصی ندارند نباید به هیچ فیلتر هدفی حل شوند.

این تغییرات تنها زمانی اعمال می‌شوند که چندین برنامه درگیر باشند و بر مدیریت قصد در یک برنامه تأثیری نمی‌گذارند.

تاثیر

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

• از ویژگی Safer Intents و مزایای آن آگاه هستید.
• فعالانه انتخاب کنید تا شیوه‌های مدیریت هدف سخت‌گیرانه‌تری را در برنامه‌های خود بگنجانید.

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

در حالی که تأثیر اولیه در اندروید 16 ممکن است محدود باشد، ابتکار Safer Intents نقشه راهی برای تأثیر گسترده تر در نسخه های آینده اندروید دارد. برنامه این است که در نهایت تصمیم گیری دقیق را به رفتار پیش فرض تبدیل کنیم.

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

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

پیاده سازی

توسعه‌دهندگان باید با استفاده از ویژگی 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 does not match component's intent filter:" و "Access blocked:" با تگ "PackageManager." این نشان دهنده یک مشکل بالقوه است که می تواند برنامه را تحت تأثیر قرار دهد و نیاز به توجه دارد.

فیلتر Logcat:

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

حریم خصوصی

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

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

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

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.

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

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.

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.

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.

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

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