مانند نسخههای قبلی، اندروید ۱۶ شامل تغییرات رفتاری است که ممکن است بر برنامه شما تأثیر بگذارد. تغییرات رفتاری زیر منحصراً برای برنامههایی اعمال میشود که اندروید ۱۶ یا بالاتر را هدف قرار میدهند. اگر برنامه شما اندروید ۱۶ یا بالاتر را هدف قرار میدهد، باید برنامه خود را برای پشتیبانی از این رفتارها، در صورت لزوم، اصلاح کنید.
حتماً فهرست تغییرات رفتاری که صرف نظر از 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 ۳۶) شامل تغییرات زیر است که قابلیتهای اصلی مختلف سیستم اندروید را اصلاح یا گسترش میدهد.
بهینهسازی زمانبندی کار با نرخ ثابت
在以 Android 16 为目标平台之前,如果 scheduleAtFixedRate 因不在有效的进程生命周期内而错过了任务执行,则当应用返回到有效的生命周期时,所有错过的执行会立即执行。
以 Android 16 为目标平台时,当应用返回到有效的生命周期时,系统会立即执行最多 1 次未执行的 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 ۳۶) شامل تغییرات زیر در رابطه با دادههای سلامت و تناسب اندام است.
مجوزهای سلامت و تناسب اندام
对于以 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_BPMWear OS 上的健康服务Sensor.TYPE_HEART_RATE来自 Android Sensor ManagerheartRateAccuracy和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 ۳۶) شامل تغییرات زیر در پشته بلوتوث برای بهبود اتصال با دستگاههای جانبی است.
اهداف جدید برای مدیریت از دست دادن اوراق قرضه و تغییرات رمزگذاری
به عنوان بخشی از بهبود مدیریت از دست دادن اوراق قرضه ، اندروید 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.
در این سناریو، برنامه شما باید به مکانیسمهای مدیریت از دست دادن اوراق قرضه موجود خود مانند نسخههای قبلی اندروید ادامه دهد تا رویدادهای از دست دادن اوراق قرضه را شناسایی و مدیریت کند.
روش جدید برای حذف اتصال بلوتوث
همه برنامههایی که اندروید 16 را هدف قرار میدهند، اکنون میتوانند با استفاده از یک API عمومی در CompanionDeviceManager ، دستگاههای بلوتوث را لغو جفت کنند. اگر یک دستگاه همراه به عنوان یک انجمن CDM مدیریت میشود، برنامه میتواند با استفاده از API جدید removeBond(int) در دستگاه مرتبط، حذف پیوند بلوتوث را آغاز کند. این برنامه میتواند با گوش دادن به رویداد پخش دستگاه بلوتوث ACTION_BOND_STATE_CHANGED تغییرات وضعیت پیوند را کنترل کند.
امنیت
اندروید ۱۶ (سطح API ۳۶) شامل تغییرات امنیتی زیر است.
قفل شدن نسخه MediaStore
برای برنامههایی که اندروید 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
برای مقاومسازی سطح پردازنده گرافیکی Mali، IOCTLهای پردازنده گرافیکی Mali که منسوخ شدهاند یا صرفاً برای توسعه پردازنده گرافیکی در نظر گرفته شدهاند، در نسخههای تولیدی مسدود شدهاند. علاوه بر این، IOCTLهای مورد استفاده برای پروفایلسازی پردازنده گرافیکی به فرآیند پوسته یا برنامههای اشکالزداییشده محدود شدهاند. برای جزئیات بیشتر در مورد سیاست سطح پلتفرم، به بهروزرسانی SAC مراجعه کنید.
این تغییر در دستگاههای پیکسل که از پردازنده گرافیکی Mali (پیکسل ۶-۹) استفاده میکنند، رخ میدهد. آرم دستهبندی رسمی IOCTL های خود را در Documentation/ioctl-categories.rst از نسخه r54p2 خود ارائه کرده است. این لیست در نسخههای درایور آینده همچنان حفظ خواهد شد.
این تغییر بر APIهای گرافیکی پشتیبانیشده (از جمله Vulkan و OpenGL) تأثیری ندارد و انتظار نمیرود که توسعهدهندگان یا برنامههای موجود را نیز تحت تأثیر قرار دهد. ابزارهای پروفایلینگ GPU مانند Streamline Performance Analyzer و Android GPU Inspector تحت تأثیر قرار نخواهند گرفت.
آزمایش
اگر با خطای عدم پذیرش SELinux مشابه تصویر زیر مواجه شدید، احتمالاً برنامه شما تحت تأثیر این تغییر قرار گرفته است:
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
اگر برنامه شما نیاز به استفاده از IOCTL های مسدود شده دارد، لطفاً یک اشکال (bug) ثبت کنید و آن را به android-partner-security@google.com ارجاع دهید.
سوالات متداول
آیا این تغییر سیاست برای همه تولیدکنندگان اصلی تجهیزات (OEM) اعمال میشود؟ این تغییر اختیاری خواهد بود، اما برای هر تولیدکننده اصلی تجهیزاتی که مایل به استفاده از این روش مقاومسازی باشند، در دسترس خواهد بود. دستورالعملهای اجرای این تغییر را میتوانید در مستندات پیادهسازی بیابید.
آیا برای پیادهسازی این تغییر، ایجاد تغییرات در کدبیس تولیدکننده اصلی (OEM) اجباری است یا اینکه بهطور پیشفرض با یک نسخه جدید AOSP همراه خواهد بود؟ تغییر در سطح پلتفرم بهطور پیشفرض با یک نسخه جدید AOSP همراه خواهد بود. فروشندگان میتوانند در صورت تمایل به اعمال این تغییر در کدبیس خود، آن را بپذیرند.
آیا SoCها مسئول بهروز نگه داشتن لیست IOCTL هستند؟ به عنوان مثال، اگر دستگاه من از پردازنده گرافیکی ARM Mali استفاده میکند، آیا باید برای هرگونه تغییر با ARM تماس بگیرم؟ SoCهای جداگانه باید لیستهای IOCTL خود را برای هر دستگاه پس از انتشار درایور بهروزرسانی کنند. به عنوان مثال، ARM لیست IOCTL منتشر شده خود را پس از بهروزرسانی درایور بهروزرسانی میکند. با این حال، OEMها باید مطمئن شوند که بهروزرسانیها را در SEPolicy خود لحاظ میکنند و در صورت نیاز، IOCTLهای سفارشی انتخاب شده را به لیستها اضافه میکنند.
آیا این تغییر به طور خودکار برای همه دستگاههای پیکسل موجود در بازار اعمال میشود یا برای اعمال این تغییر، اقدام کاربر لازم است؟ این تغییر برای همه دستگاههای پیکسل موجود در بازار که از پردازنده گرافیکی Mali استفاده میکنند (پیکسل ۶-۹) اعمال میشود. برای اعمال این تغییر نیازی به اقدام کاربر نیست.
آیا استفاده از این سیاست بر عملکرد درایور هسته تأثیر میگذارد؟ این سیاست با استفاده از GFXBench روی پردازنده گرافیکی Mali آزمایش شد و هیچ تغییر قابل اندازهگیری در عملکرد پردازنده گرافیکی مشاهده نشد.
آیا لازم است لیست IOCTL با نسخههای فعلی درایور فضای کاربری و هسته هماهنگ شود؟ بله، لیست IOCTLهای مجاز باید با IOCTLهای پشتیبانی شده توسط درایورهای فضای کاربری و هسته هماهنگ شوند. اگر IOCTLهای موجود در فضای کاربری یا درایور هسته بهروزرسانی شوند، لیست IOCTL در SEPolicy نیز باید بهروزرسانی شود تا با آنها مطابقت داشته باشد.
ARM، IOCTLها را به عنوان «محدود» / «ابزار دقیق» طبقهبندی کرده است، اما ما میخواهیم از برخی از آنها در موارد استفاده در تولید استفاده کنیم و/یا برخی دیگر را رد کنیم. تولیدکنندگان اصلی تجهیزات/SoCها مسئول تصمیمگیری در مورد نحوه طبقهبندی IOCTLهایی هستند که بر اساس پیکربندی کتابخانههای Mali فضای کاربری خود، استفاده میکنند. فهرست ARM میتواند برای تصمیمگیری در مورد این موارد استفاده شود، اما موارد استفاده هر تولیدکننده اصلی تجهیزات/SoC ممکن است متفاوت باشد.
حریم خصوصی
اندروید ۱۶ (سطح API ۳۶) شامل تغییرات حریم خصوصی زیر است.
مجوز شبکه محلی
具有 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) 也被归类为本地网络地址。