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

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

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

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

Android 16 (سطح API‏ ۳۶) شامل تغییرات زیر است که هدف از آن‌ها ایجاد تجربه کاربری یکپارچه‌تر و شهودی‌تر است.

انصراف از لبه‌به‌لبه درحال حذف شدن است

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

• اگر برنامه شما Android 16 (سطح میانای برنامه‌سازی کاربردی ۳۶) را هدف قرار دهد و در دستگاه Android 15 اجرا شود، R.attr#windowOptOutEdgeToEdgeEnforcement همچنان کار می‌کند.
• اگر برنامه شما Android 16 (میانای برنامه‌سازی کاربردی سطح ۳۶) را هدف‌یابی می‌کند و در دستگاه Android 16 اجرا می‌شود، R.attr#windowOptOutEdgeToEdgeEnforcement غیرفعال است.

برای آزمایش در Android 16، مطمئن شوید برنامه‌تان از لبه‌به‌لبه پشتیبانی می‌کند و هرگونه استفاده از R.attr#windowOptOutEdgeToEdgeEnforcement را بردارید تا برنامه‌تان در دستگاه Android 15 نیز از لبه‌به‌لبه پشتیبانی کند. برای پشتیبانی از لبه‌به‌لبه، راهنمای Compose و نماها را ببینید.

برای اشاره برگشت پیش‌گویانه، انتقال یا انصراف دادن لازم است

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

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

میاناهای برنامه‌سازی کاربردی قلم Elegant منسوخ و غیرفعال شده‌اند

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

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

عملکرد اصلی

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

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

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

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

ضریب‌های شکل دستگاه

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

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

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

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

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

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

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

تغییرات ناگهانی رایج

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

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

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

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

• 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‏ ۳۶) را هدف قرار می‌دهند، محدودیت‌های جهت، قابلیت تغییر اندازه، و نسبت ابعادی برنامه به‌طور پیش‌فرض در صفحه‌نمایش‌های بزرگ نادیده گرفته می‌شود. هر برنامه‌ای که کاملاً آماده نباشد می‌تواند با انصراف دادن، موقتاً این رفتار را لغو کند که منجر به رفتار قبلی قرار گرفتن در حالت سازگاری می‌شود.

استثناها

محدودیت‌های جهت، قابلیت تغییر اندازه، و نسبت ابعادی 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>

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

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

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

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

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

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

• برای پایش «ضربان قلب»، «سطح اکسیژن خون»، یا «دمای پوست» درحین استفاده: اجازه جزئی را تحت android.permissions.health درخواست کنید، مثلاً READ_HEART_RATE به‌جای BODY_SENSORS.
• برای دسترسی به حسگر پس‌زمینه: READ_HEALTH_DATA_IN_BACKGROUND را به‌جای BODY_SENSORS_BACKGROUND درخواست کنید.

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

برنامه‌های دستگاه همراه

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

اتصال‌پذیری

Android 16 (سطح 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 تغییرات وضعیت پیوند را کنترل کند.

امنیت

Android 16 (سطح میانای برنامه‌سازی کاربردی ۳۶) شامل تغییرات امنیتی زیر است.

قفل کردن نسخه MediaStore

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

قصد‌های ایمن‌تر

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

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

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

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

2. «قصد» بدون کنش نمی‌تواند با هیچ «فیلتر قصدی» مطابقت داشته باشد: «قصد»هایی که کنش مشخصی ندارند نباید به هیچ «فیلتر قصدی» ارجاع داده شوند.

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

تأثیر

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

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

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

اگرچه تأثیر اولیه در Android 16 ممکن است محدود باشد، طرح «قصدهای ایمن‌تر» نقشه راهی برای تأثیر گسترده‌تر در نسخه‌های آتی Android دارد. برنامه این است که درنهایت وضوح قصد سخت‌گیرانه را به رفتار پیش‌فرض تبدیل کنیم.

ویژگی «هدف‌های ایمن‌تر» این پتانسیل را دارد که با دشوارتر کردن سوءاستفاده برنامه‌های مخرب از آسیب‌پذیری‌های سازوکار حل هدف، امنیت بوم‌سازگان Android را به‌طور قابل‌توجهی افزایش دهد.

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

پیاده‌سازی

توسعه‌دهندگان باید بااستفاده از مشخصه 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:")

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

برای تقویت سطح Mali GPU، Mali GPU IOCTLهایی که منسوخ شده‌اند یا صرفاً برای توسعه GPU درنظر گرفته شده‌اند در نسخه‌های تولیدی مسدود شده‌اند. علاوه‌براین، IOCTLهای مورداستفاده برای نمایه‌سازی GPU به فرایند پوسته یا برنامه‌های قابل‌اشکال‌زدایی محدود شده‌اند. برای جزئیات بیشتر درباره خط‌مشی سطح پلاتفرم، به به‌روزرسانی SAC مراجعه کنید.

این تغییر در دستگاه‌های Pixel که از Mali GPU (Pixel 6-9) استفاده می‌کنند اعمال می‌شود. Arm دسته‌بندی رسمی IOCTLهای خود را در Documentation/ioctl-categories.rst از نسخه r54p2 خود ارائه کرده است. این فهرست در نسخه‌های پخش بعدی درایور همچنان حفظ خواهد شد.

این تغییر بر میاناهای برنامه‌سازی کاربردی گرافیکی پشتیبانی‌شده (ازجمله 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های مسدودشده دارد، لطفاً اشکالی ثبت کنید و آن را به android-partner-security@google.com اختصاص دهید.

پرسشگان

1. آیا این تغییر خط‌مشی برای همه سازندگان تجهیزات اصلی اعمال می‌شود؟ این تغییر به‌صورت موافقت کردن خواهد بود، اما برای هر OEM که بخواهد از این روش مقاوم‌سازی استفاده کند دردسترس است. دستورالعمل‌های اجرای این تغییر را می‌توانید در اسناد پیاده‌سازی پیدا کنید.

2. آیا برای پیاده‌سازی این ویژگی، ایجاد تغییرات در پایگاه کد سازنده اصلی محصول اجباری است یا به‌طور پیش‌فرض با نسخه جدید «پروژه متن‌باز Android» ارائه می‌شود؟ تغییر سطح پلاتفرم به‌طور پیش‌فرض با نسخه جدید AOSP ارائه خواهد شد. فروشندگان می‌توانند این تغییر را در پایگاه کد خود بپذیرند اگر بخواهند آن را اعمال کنند.

3. آیا SoCها مسئول به‌روز نگه داشتن فهرست IOCTL هستند؟ برای مثال، اگر دستگاه من از ARM Mali GPU استفاده می‌کند، آیا برای هریک از تغییرات باید با ARM تماس بگیرم؟ هر SoC باید فهرست IOCTL خود را برای هر دستگاه پس‌از انتشار درایور به‌روز کند. برای مثال، ARM فهرست IOCTL منتشرشده خود را پس‌از به‌روزرسانی‌های درایور به‌روز می‌کند. بااین‌حال، سازندگان تجهیزات اصلی باید مطمئن شوند که به‌روزرسانی‌ها را در SEPolicy خود ادغام می‌کنند و هر IOCTL سفارشی انتخاب‌شده را درصورت نیاز به فهرست‌ها اضافه می‌کنند.

4. آیا این تغییر به‌طور خودکار برای همه دستگاه‌های Pixel موجود در بازار اعمال می‌شود یا برای اعمال این تغییر، کاربر باید اقدامی انجام دهد؟ این تغییر برای همه دستگاه‌های Pixel موجود در بازار که از واحد پردازش گرافیکی Mali استفاده می‌کنند (Pixel 6-9) اعمال می‌شود. برای اعمال این تغییر، نیازی به اقدام کاربر نیست.

5. آیا استفاده از این خط‌مشی بر عملکرد درایور هسته تأثیر می‌گذارد؟ این خط‌مشی در Mali GPU بااستفاده از GFXBench آزمایش شد و هیچ تغییر قابل‌اندازه‌گیری‌ای در عملکرد GPU مشاهده نشد.

6. آیا لازم است فهرست IOCTL با نسخه‌های فعلی فضای کاربر و درایور هسته مطابقت داشته باشد؟ بله، فهرست IOCTLهای مجاز باید با IOCTLهای پشتیبانی‌شده توسط درایورهای فضای کاربر و هسته همگام‌سازی شود. اگر IOCTL در فضای کاربر یا درایور هسته به‌روز شود، فهرست IOCTL در SEPolicy باید به‌روز شود تا مطابقت داشته باشد.

7. ‫ARM دستورات IOCTL را به‌عنوان «محدودشده» / «ابزار دقیق» دسته‌بندی کرده است، اما می‌خواهیم از برخی‌از آن‌ها در موارد استفاده تولیدی استفاده کنیم و/یا برخی دیگر را رد کنیم. تولیدکنندگان اصلی سخت‌افزار/سیستم‌های روی تراشه به‌صورت جداگانه مسئول تصمیم‌گیری درباره نحوه دسته‌بندی IOCTLهایی هستند که استفاده می‌کنند، براساس پیکربندی کتابخانه‌های Mali فضای کاربر آن‌ها. می‌توان از فهرست ARM برای کمک به تصمیم‌گیری درباره این موارد استفاده کرد، اما مورد استفاده هر OEM/SoC ممکن است متفاوت باشد.

حریم خصوصی

Android 16 (سطح API‏ ۳۶) شامل تغییرات حریم خصوصی زیر است.

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

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

هدف پروژه «محافظت از شبکه محلی» محافظت از حریم خصوصی کاربر ازطریق محدود کردن دسترسی به شبکه محلی با یک اجازه زمان اجرای جدید است.

طرح انتشار

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

تأثیر

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

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

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

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

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

استثنائات قوانین بالا:

• اگر سرور DNS دستگاهی در شبکه محلی باشد، ترافیک ورودی یا خروجی آن (در درگاه ۵۳) به اجازه دسترسی به شبکه محلی نیاز ندارد.
• برنامه‌هایی که از «تعویض‌کننده خروجی» به‌عنوان انتخابگر درون‌برنامه‌ای خود استفاده می‌کنند، به اجازه‌های شبکه محلی نیاز نخواهند داشت (راهنمایی‌های بیشتر در سه‌ماهه چهارم ۲۰۲۵ ارائه خواهد شد).

راهنمای توسعه‌دهنده (موافقت کردن)

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

1. دستگاه را به ساخت با 25Q2 Beta 3 یا جدیدتر فلش کنید.
2. برنامه موردنظر را برای آزمایش نصب کنید.

3. پرچم Appcompat را در adb تغییر دهید:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. بازراه‌اندازی دستگاه

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

برای بازیابی دسترسی، باید به برنامه‌تان اجازه دسترسی به NEARBY_WIFI_DEVICES را اعطا کنید.

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

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

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

از فرمان زیر برای خاموش کردن پرچم App-Compat استفاده کنید

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

خطاها

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

نمونه خطاها:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

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

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

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

پروتکل اینترنتی نسخه ۴:

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

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

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

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