تغييرات في السلوك: التطبيقات التي تستهدف الإصدار 16 من نظام التشغيل Android أو الإصدارات الأحدث

كما هو الحال في الإصدارات السابقة، يتضمّن Android 16 تغييرات في السلوك قد تؤثّر في تطبيقك. تنطبق تغييرات السلوك التالية حصريًا على التطبيقات التي تستهدف Android 16 أو الإصدارات الأحدث. إذا كان تطبيقك يستهدف الإصدار 16 من نظام التشغيل Android أو الإصدارات الأحدث، عليك تعديل تطبيقك ليتوافق مع هذه السلوكيات، حيثما ينطبق ذلك.

احرص أيضًا على مراجعة قائمة التغييرات في السلوك التي تؤثر في جميع التطبيقات التي تعمل على Android 16 بغض النظر عن targetSdkVersion لتطبيقك.

تجربة المستخدم وواجهة مستخدم النظام

يتضمّن نظام التشغيل Android 16 (المستوى 36 من واجهة برمجة التطبيقات) التغييرات التالية التي تهدف إلى توفير تجربة مستخدم أكثر اتساقًا وسهولة.

إيقاف العرض من الحافة إلى الحافة نهائيًا

فرض الإصدار 15 من نظام التشغيل Android ميزة "العرض حتى حافة الشاشة" على التطبيقات التي تستهدف الإصدار 15 من نظام التشغيل Android (المستوى 35 لواجهة برمجة التطبيقات)، ولكن يمكن لتطبيقك إيقاف هذه الميزة من خلال ضبط R.attr#windowOptOutEdgeToEdgeEnforcement على true. بالنسبة إلى التطبيقات التي تستهدف الإصدار 16 من نظام التشغيل Android (المستوى 36 لواجهة برمجة التطبيقات)، تم إيقاف R.attr#windowOptOutEdgeToEdgeEnforcement نهائيًا، ولا يمكن لتطبيقك إيقاف ميزة "العرض حتى حافة الشاشة".

• إذا كان تطبيقك يستهدف الإصدار 16 من نظام التشغيل Android (المستوى 36 لواجهة برمجة التطبيقات) ويعمل على جهاز Android 15، سيستمر عمل R.attr#windowOptOutEdgeToEdgeEnforcement.
• إذا كان تطبيقك يستهدف الإصدار 16 من نظام التشغيل Android (المستوى 36 لواجهة برمجة التطبيقات) ويعمل على جهاز Android 16، سيتم إيقاف R.attr#windowOptOutEdgeToEdgeEnforcement.

لإجراء الاختبار على Android 16، تأكَّد من أنّ تطبيقك يتوافق مع وضع ملء الشاشة، وأزِل أي استخدام للرمز R.attr#windowOptOutEdgeToEdgeEnforcement لكي يتوافق تطبيقك أيضًا مع وضع ملء الشاشة على جهاز Android 15. لإتاحة العرض من الحافة إلى الحافة، راجِع إرشادات Compose وViews.

يجب نقل البيانات أو إيقاف ميزة "الرجوع التنبؤي"

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

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

إيقاف واجهات برمجة التطبيقات الخاصة بالخطوط الأنيقة نهائيًا

في التطبيقات التي تستهدف الإصدار 15 من نظام التشغيل Android (المستوى 35 لواجهة برمجة التطبيقات)، يتم ضبط السمة elegantTextHeight TextView على القيمة true تلقائيًا، ما يؤدي إلى استبدال الخط المضغوط بخط أكثر قابلية للقراءة. يمكنك إلغاء هذا الإعداد من خلال ضبط السمة elegantTextHeight على false.

في الإصدار 16 من نظام التشغيل Android، سيتم إيقاف السمة elegantTextHeight، وسيتم تجاهل السمة عندما يستهدف تطبيقك الإصدار 16 من نظام التشغيل Android. سيتم إيقاف "خطوط واجهة المستخدم" التي تتحكّم فيها واجهات برمجة التطبيقات هذه، لذا عليك تعديل أي تخطيطات لضمان عرض النص بشكل متسق ومناسب للمستقبل باللغات العربية أو اللاوية أو البورمية أو التاميلية أو الغوجاراتية أو الكنادية أو المالايالامية أو الأودية أو التيلوغوية أو التايلاندية.

سلوك

سلوك

الوظيفة الأساسية

يتضمّن نظام التشغيل Android 16 (المستوى 36 لواجهة برمجة التطبيقات) التغييرات التالية التي تعدّل أو توسّع العديد من الإمكانات الأساسية لنظام Android.

تحسين جدولة العمل بمعدّل ثابت

قبل استهداف الإصدار 16 من Android، عندما يفوت scheduleAtFixedRate تنفيذ مهمة بسبب عدم التزامه بدورة حياة صالحة للعمليات، يتم تنفيذ جميع عمليات التنفيذ الفائتة على الفور عند عودة التطبيق إلى دورة حياة صالحة.

عند استهداف Android 16، يتم تنفيذ مرة واحدة على الأكثر من عملية تنفيذ scheduleAtFixedRate الفائتة على الفور عندما يعود التطبيق إلى دورة حياة صالحة. من المتوقّع أن يؤدي تغيير السلوك هذا إلى تحسين أداء التطبيق. يمكنك اختبار هذا السلوك في تطبيقك لمعرفة ما إذا كان تطبيقك متأثرًا. يمكنك أيضًا إجراء الاختبار باستخدام إطار عمل توافق التطبيقات وتفعيل علامة التوافق STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS.

أشكال الأجهزة

يتضمّن نظام التشغيل Android 16 (المستوى 36 من واجهة برمجة التطبيقات) التغييرات التالية للتطبيقات عند عرضها على الأجهزة ذات الشاشات الكبيرة.

التنسيقات التكيّفية

بما أنّ تطبيقات Android تعمل الآن على مجموعة متنوعة من الأجهزة (مثل الهواتف والأجهزة اللوحية والأجهزة القابلة للطي وأجهزة الكمبيوتر المكتبي والسيارات وأجهزة التلفزيون) وأوضاع النوافذ على الشاشات الكبيرة (مثل وضع تقسيم الشاشة ووضع النوافذ على أجهزة الكمبيوتر)، على المطوّرين إنشاء تطبيقات Android تتكيّف مع أي حجم للشاشة والنافذة، بغض النظر عن اتجاه الجهاز. إنّ نماذج الاستخدام، مثل حظر تغيير الاتجاه وتغيير الحجم، أصبحت مقيّدة جدًا في عالم الأجهزة المتعددة اليوم.

تجاهل القيود المفروضة على الاتجاه وإمكانية تغيير الحجم ونسبة العرض إلى الارتفاع

بالنسبة إلى التطبيقات التي تستهدف الإصدار 16 من نظام التشغيل Android (المستوى 36 لواجهة برمجة التطبيقات)، يتضمّن هذا الإصدار تغييرات في طريقة إدارة النظام لقيود الاتجاه وتغيير الحجم ونسبة العرض إلى الارتفاع. على الشاشات التي يبلغ عرضها الأصغر 600 وحدة بكسل مستقلة عن الكثافة أو أكثر، لا تنطبق القيود. تتجاهل التطبيقات أيضًا نسبة العرض إلى الارتفاع أو اتجاه الشاشة المفضّل لدى المستخدم، وتملأ نافذة العرض بأكملها، ولا يتم استخدام تنسيق العمودين الجانبيين.

يقدّم هذا التغيير سلوكًا جديدًا للمنصة. يتجه نظام التشغيل 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 (المستوى 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>

الصحة واللياقة البدنية

يتضمّن نظام التشغيل Android 16 (المستوى 36 من واجهة برمجة التطبيقات) التغييرات التالية المتعلّقة ببيانات الصحة واللياقة البدنية.

أذونات الصحة واللياقة البدنية

بالنسبة إلى التطبيقات التي تستهدف الإصدار Android 16 (المستوى 36 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث، تستخدم أذونات BODY_SENSORS أذونات أكثر دقة ضمن android.permissions.health، والتي يستخدمها أيضًا Health Connect. اعتبارًا من الإصدار 16 من نظام التشغيل Android، أي واجهة برمجة تطبيقات كانت تتطلّب في السابق BODY_SENSORS أو BODY_SENSORS_BACKGROUND أصبحت الآن تتطلّب الإذن المقابل android.permissions.health بدلاً من ذلك. ويؤثّر ذلك في أنواع البيانات وواجهات برمجة التطبيقات وأنواع الخدمات التي تعمل في المقدّمة التالية:

• HEART_RATE_BPM من "خدمات الصحة" على 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 (المستوى 36 لواجهة برمجة التطبيقات) التغييرات التالية في حزمة بروتوكول البلوتوث لتحسين إمكانية الاتصال بالأجهزة الطرفية.

أهداف جديدة للتعامل مع فقدان الربط والتغييرات في التشفير

As part of the Improved bond loss handling, Android 16 also introduces 2 new intents to provide apps with greater awareness of bond loss and encryption changes.

Apps targeting Android 16 can now:

• Receive an ACTION_KEY_MISSING intent when remote bond loss is detected, allowing them to provide more informative user feedback and take appropriate actions.
• Receive an ACTION_ENCRYPTION_CHANGE intent whenever encryption status of the link changes. This includes encryption status change, encryption algorithm change, and encryption key size change. Apps must consider the bond restored if the link is successfully encrypted upon receiving ACTION_ENCRYPTION_CHANGE intent later.

Adapting to varying OEM implementations

While Android 16 introduces these new intents, their implementation and broadcasting can vary across different device manufacturers (OEMs). To ensure your app provides a consistent and reliable experience across all devices, developers should design their bond loss handling to gracefully adapt to these potential variations.

We recommend the following app behaviors:

• If the ACTION_KEY_MISSING intent is broadcast:

  The ACL (Asynchronous Connection-Less) link will be disconnected by the system, but the bond information for the device will be retained (as described here).

  Your app should use this intent as the primary signal for bond loss detection and guiding the user to confirm the remote device is in range before initiating device forgetting or re-pairing.

  If a device disconnects after ACTION_KEY_MISSING is received, your app should be cautious about reconnecting, as the device may no longer be bonded with the system.

• If the ACTION_KEY_MISSING intent is NOT broadcast:

  The ACL link will remain connected, and the bond information for the device will be removed by the system, same to behavior in Android 15.

  In this scenario, your app should continue its existing bond loss handling mechanisms as in previous Android releases, to detect and manage bond loss events.

طريقة جديدة لإزالة ربط البلوتوث

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.

الأمان

يتضمّن نظام التشغيل Android 16 (المستوى 36 لواجهة برمجة التطبيقات) تغييرات الأمان التالية.

قفل إصدار MediaStore

بالنسبة إلى التطبيقات التي تستهدف الإصدار 16 من نظام التشغيل Android أو الإصدارات الأحدث، سيصبح MediaStore#getVersion() فريدًا لكل تطبيق. ويؤدي ذلك إلى إزالة السمات التعريفية من سلسلة الإصدار لمنع إساءة الاستخدام والاستفادة من تقنيات تحديد الهوية. ويجب ألا تفترض التطبيقات أيّ شيء بشأن تنسيق هذا الإصدار. من المفترض أن تتمكّن التطبيقات من التعامل مع تغييرات الإصدار عند استخدام واجهة برمجة التطبيقات هذه، وفي معظم الحالات، لن تحتاج التطبيقات إلى تغيير سلوكها الحالي، ما لم يحاول المطوّر استنتاج معلومات إضافية تتجاوز النطاق المقصود لواجهة برمجة التطبيقات هذه.

Safer Intents

ميزة "نقل نوايا أكثر أمانًا" هي مبادرة أمان متعدّدة المراحل مصمَّمة لتحسين أمان آلية تحديد الغرض في Android. والهدف من ذلك هو حماية التطبيقات من الإجراءات الضارة من خلال إضافة عمليات تحقّق أثناء معالجة الأهداف وتصفية الأهداف التي لا تستوفي معايير محدّدة.

في Android 15، ركّزت الميزة على تطبيق المرسِل، ولكن مع Android 16، أصبح تطبيق المتلقي هو الذي يتحكّم في العملية، ما يتيح للمطوّرين تفعيل ميزة تحليل الأهداف بدقة باستخدام بيان التطبيق.

سيتم تنفيذ تغييران رئيسيان:

1. يجب أن تتطابق الأهداف الصريحة (Explicit Intents) مع فلتر Intent الخاص بالمكوِّن المستهدف: إذا كانت الأهداف الصريحة تستهدف مكوِّنًا بشكل صريح، يجب أن تتطابق مع فلتر Intent الخاص بهذا المكوِّن.

2. لا يمكن أن تتطابق الأهداف التي لا تتضمّن إجراءً مع أي فلتر Intent: يجب ألا يتم تحليل الأهداف التي لا تتضمّن إجراءً محدّدًا إلى أي فلتر Intent.

لا تنطبق هذه التغييرات إلا عند استخدام تطبيقات متعددة، ولا تؤثّر في معالجة الأهداف داخل تطبيق واحد.

التأثير

ويعني ذلك أنّ على المطوّرين تفعيلها بشكل صريح في بيان التطبيق لكي تصبح سارية. نتيجةً لذلك، سيقتصر تأثير الميزة على التطبيقات التي يستوفي مطوّروها الشروط التالية:

• أن تكون على دراية بميزة "نوايا أكثر أمانًا" وفوائدها
• اختيار دمج ممارسات أكثر صرامة للتعامل مع الأهداف في تطبيقاتهم

يقلّل نهج الموافقة هذا من خطر تعطيل التطبيقات الحالية التي قد تعتمد على السلوك الحالي الأقل أمانًا في حلّ الأهداف.

على الرغم من أنّ التأثير الأوّلي لمبادرة "نوايا أكثر أمانًا" في 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:")

فلترة طلبات النظام لوحدة معالجة الرسومات

لتعزيز أمان واجهة Mali GPU، تم حظر عمليات إدخال/إخراج وحدة معالجة الرسومات Mali التي تم إيقافها نهائيًا أو التي تم تصميمها فقط لتطوير وحدة معالجة الرسومات في إصدارات الإنتاج. بالإضافة إلى ذلك، تم حصر استخدام IOCTLs لتحديد مواصفات وحدة معالجة الرسومات في عملية shell أو التطبيقات التي يمكن تصحيح أخطائها. يُرجى الرجوع إلى التعديل على "اتفاقية المطوّرين للنشر على Android" لمعرفة المزيد من التفاصيل حول السياسة على مستوى المنصة.

يحدث هذا التغيير على أجهزة Pixel التي تستخدم وحدة معالجة الرسومات Mali (من Pixel 6 إلى Pixel 9). قدّمت شركة Arm تصنيفًا رسميًا لرموز IOCTL في Documentation/ioctl-categories.rst من الإصدار r54p2. وسيتم مواصلة صيانة هذه القائمة في إصدارات برامج التشغيل المستقبلية.

لا يؤثّر هذا التغيير في واجهات برمجة التطبيقات المتوافقة مع الرسومات (بما في ذلك Vulkan وOpenGL)، ومن غير المتوقّع أن يؤثّر في المطوّرين أو التطبيقات الحالية. لن تتأثر أدوات تحليل أداء وحدة معالجة الرسومات، مثل 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

إذا كان تطبيقك بحاجة إلى استخدام IOCTLs محظورة، يُرجى الإبلاغ عن الخطأ وتعيينه إلى android-partner-security@google.com.

الأسئلة الشائعة

1. هل ينطبق هذا التغيير في السياسة على جميع الشركات المصنّعة الأصلية للأجهزة؟ سيكون هذا التغيير اختياريًا، ولكنّه سيكون متاحًا لأي مصنّعين أصليين للأجهزة يريدون استخدام طريقة الحماية هذه. يمكنك الاطّلاع على تعليمات تنفيذ التغيير في مستندات التنفيذ.

2. هل من الضروري إجراء تغييرات في قاعدة رموز المصنّع الأصلي للأجهزة لتنفيذ ذلك، أم أنّها تأتي مع إصدار جديد من "المشروع المفتوح المصدر لنظام Android" (AOSP) تلقائيًا؟ سيتم طرح التغيير على مستوى النظام الأساسي مع إصدار جديد من AOSP تلقائيًا. يمكن للمورّدين الموافقة على هذا التغيير في قاعدة الرموز الخاصة بهم إذا كانوا يريدون تطبيقه.

3. هل يكون مورّدو الأنظمة على الرقاقات مسؤولين عن تعديل قائمة IOCTL؟ على سبيل المثال، إذا كان جهازي يستخدم وحدة معالجة الرسومات ARM Mali، هل عليّ التواصل مع ARM لإجراء أي من التغييرات؟ يجب أن تعدّل أنظمة SoC الفردية قوائم IOCTL لكل جهاز عند إصدار برنامج التشغيل. على سبيل المثال، ستعدّل ARM قائمة IOCTL المنشورة عند تحديث برامج التشغيل. ومع ذلك، على المصنّعين الأصليين للأجهزة التأكّد من تضمين التعديلات في سياسة SELinux، وإضافة أي أوامر IOCTL مخصّصة تم اختيارها إلى القوائم حسب الحاجة.

4. هل يتم تطبيق هذا التغيير تلقائيًا على جميع أجهزة Pixel المتوفرة في السوق، أم يجب أن يتّخذ المستخدم إجراءً لتفعيل خيار ما من أجل تطبيق هذا التغيير؟ ينطبق هذا التغيير على جميع أجهزة Pixel المتوفّرة في السوق والتي تستخدم وحدة معالجة الرسومات Mali (من Pixel 6 إلى Pixel 9). ليس على المستخدم اتخاذ أي إجراء لتطبيق هذا التغيير.

5. هل سيؤثر استخدام هذه السياسة في أداء برنامج تشغيل النواة؟ تم اختبار هذه السياسة على وحدة معالجة الرسومات Mali باستخدام GFXBench، ولم يتم رصد أي تغيير قابل للقياس في أداء وحدة معالجة الرسومات.

6. هل من الضروري أن تتوافق قائمة IOCTL مع إصدارات مساحة المستخدم وبرنامج تشغيل النواة الحالية؟ نعم، يجب مزامنة قائمة IOCTL المسموح بها مع IOCTL المتوافقة مع برامج تشغيل مساحة المستخدم وبرامج تشغيل النواة. في حال تعديل IOCTLs في مساحة المستخدم أو برنامج تشغيل النواة، يجب تعديل قائمة SEPolicy IOCTL لتتطابق مع التعديل.

7. صنّفت ARM عمليات IOCTL على أنّها "محظورة" أو "أدوات قياس"، ولكنّنا نريد استخدام بعضها في حالات الاستخدام الفعلي و/أو رفض البعض الآخر. يتحمّل مصنّعو المعدات الأصلية/أنظمة التشغيل على الرقاقة الفردية مسؤولية تحديد كيفية تصنيف IOCTL التي يستخدمونها، وذلك استنادًا إلى إعدادات مكتبات Mali الخاصة بمساحة المستخدم. يمكن استخدام قائمة ARM للمساعدة في تحديد هذه الحالات، ولكن قد تختلف حالة الاستخدام لكل مصنّع معدات أصلية/نظام على شريحة.

الخصوصية

يتضمّن نظام التشغيل Android 16 (المستوى 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 26Q2 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.

الصور التي يملكها التطبيق

عندما يطلب تطبيق يستهدف الإصدار 36 من حزمة SDK أو إصدارًا أحدث على الأجهزة التي تعمل بالإصدار 16 من نظام التشغيل Android أو إصدارًا أحدث أذونات الوصول إلى الصور والفيديوهات، سيظهر للمستخدمين الذين يختارون حصر الوصول إلى الوسائط المحدّدة أي صور يملكها التطبيق تم اختيارها مسبقًا في أداة اختيار الصور. يمكن للمستخدمين إلغاء اختيار أي من هذه العناصر المحدّدة مسبقًا، ما سيؤدي إلى إبطال إذن وصول التطبيق إلى هذه الصور والفيديوهات.