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

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

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

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

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

إيقاف خيار عدم تفعيل ميزة "العرض حتى حافة الشاشة"

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

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

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

يجب نقل البيانات أو إيقاف ميزة "إيماءة إظهار شاشة الرجوع"

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

إذا كان تطبيقك يعترض حدث الرجوع ولم تنتقل إلى ميزة "إيماءة إظهار شاشة الرجوع" بعد، حدِّث تطبيقك لاستخدام واجهات برمجة التطبيقات المتوافقة للتنقّل للخلف أو أوقِف الميزة مؤقتًا من خلال ضبط السمة android:enableOnBackInvokedCallback على false في علامة <application> أو <activity> لملف AndroidManifest.xml في تطبيقك.

تم إيقاف واجهات برمجة التطبيقات Elegant font نهائيًا وتعطيلها

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

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

سلوك

سلوك

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

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

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

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

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

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

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

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

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

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

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

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

بالنسبة إلى التطبيقات التي تستهدف الإصدار 16 من نظام التشغيل Android (مستوى واجهة برمجة التطبيقات 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 من واجهة برمجة التطبيقات) التغييرات التالية المتعلّقة ببيانات الصحة واللياقة البدنية.

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

بالنسبة إلى التطبيقات التي تستهدف الإصدار 16 من نظام التشغيل Android (المستوى 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 Sensor Manager
• 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.

إمكانية الاتصال

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

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

كجزء من المعالجة المحسّنة لفقدان الربط، يقدّم نظام التشغيل Android 16 أيضًا هدفَين جديدَين لمنح التطبيقات وعيًا أكبر بفقدان الربط وتغييرات التشفير.

يمكن للتطبيقات التي تستهدف الإصدار 16 من Android الآن تنفيذ ما يلي:

• تلقّي نية ACTION_KEY_MISSING عند رصد فقدان الربط عن بُعد ، ما يتيح لهم تقديم ملاحظات أكثر إفادة للمستخدمين واتّخاذ الإجراءات المناسبة
• تلقّي نية ACTION_ENCRYPTION_CHANGE عند تغيير حالة التشفير للرابط ويشمل ذلك تغيير حالة التشفير وتغيير خوارزمية التشفير وتغيير حجم مفتاح التشفير. يجب أن تُعتبر التطبيقات قد أعادت الربط إذا تم تشفير الرابط بنجاح عند تلقّي ACTION_ENCRYPTION_CHANGE intent لاحقًا.

التكيّف مع عمليات التنفيذ المختلفة التي يجريها المصنّعون الأصليون للأجهزة

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

ننصحك باتّباع سلوكيات التطبيقات التالية:

• في حال بثّ نية ACTION_KEY_MISSING:

  سيقطع النظام ربط ACL (الربط غير المتزامن)، ولكن سيتم الاحتفاظ بمعلومات الربط للجهاز (على النحو описан هنا).

  يجب أن يستخدم تطبيقك هذا الإذن كإشارة أساسية لرصد فقدان الربط وإرشاد المستخدم إلى التأكّد من أنّ الجهاز البعيد ضمن النطاق قبل بدء عملية محو بيانات الجهاز أو إعادة إقرانه.

  إذا انقطع اتصال أحد الأجهزة بعد تلقّي ACTION_KEY_MISSING، يجب أن يتعامل تطبيقك بحذر مع إعادة الاتصال، لأنّه قد لا يكون الجهاز مرتبطًا بالنظام بعد ذلك.

• في حال عدم بث نية ACTION_KEY_MISSING:

  سيظل رابط ACL متصلاً، وسيزيل النظام معلومات الربط للجهاز، تمامًا كما هو الحال في Android 15.

  في هذا السيناريو، من المفترض أن يواصل تطبيقك استخدام آليات التعامل مع فقدان الربط الحالية كما في إصدارات Android السابقة، لرصد أحداث فقدان الربط وإدارتها.

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

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

الأمان

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

قفل إصدار MediaStore

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

أهداف أكثر أمانًا

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

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

سيتم تطبيق تغييرَين رئيسيَين:

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

2. لا يمكن أن تتطابق رسائل Intent التي لا تتضمّن إجراءً مع أي intent filter: لا يمكن حلّ رسائل Intent التي لا تتضمّن إجراءً محدّدًا مع أي intent filter.

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

التأثير

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

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

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

على الرغم من أنّ التأثير الأوّلي لمبادرة "نوايا أكثر أمانًا" في 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، تم حظر IOCTLs لوحدة معالجة الرسومات Mali التي تم إيقافها نهائيًا أو التي تم تصميمها فقط لتطوير وحدة معالجة الرسومات في إصدارات الإنتاج. بالإضافة إلى ذلك، تم حصر استخدام IOCTLs المستخدَمة في تحليل أداء وحدة معالجة الرسومات على عملية واجهة الأوامر أو التطبيقات القابلة للتصحيح. يُرجى الرجوع إلى تعديل SAC لمزيد من التفاصيل حول السياسة على مستوى المنصة.

يتم تطبيق هذا التغيير على أجهزة 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) تلقائيًا؟ سيتم تطبيق التغيير على مستوى النظام الأساسي مع إصدار جديد من "مشروع Android المفتوح المصدر" (AOSP) تلقائيًا. ويمكن للمورّدين الموافقة على هذا التغيير في قاعدة الرموز البرمجية إذا أرادوا تطبيقه.

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

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

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

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

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

الخصوصية

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

إذن الوصول إلى الشبكة المحلية

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

يهدف مشروع "الحماية على الشبكة المحلية" إلى حماية خصوصية المستخدم من خلال تقييد الوصول إلى الشبكة المحلية باستخدام إذن تشغيل جديد.

خطة الإصدار

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

التأثير

في المرحلة الحالية، تُعدّ ميزة LNP اختيارية، ما يعني أنّها ستؤثر فقط في التطبيقات التي تفعّلها. الهدف من مرحلة الموافقة هو أن يفهم مطوّرو التطبيقات الأجزاء التي تعتمد على الوصول الضمني إلى الشبكة المحلية في تطبيقاتهم، حتى يتمكّنوا من الاستعداد لحمايتها من خلال الأذونات في الإصدار التالي.

ستتأثر التطبيقات إذا كانت تصل إلى الشبكة المحلية للمستخدم باستخدام:

• استخدام المقابس الأولية بشكل مباشر أو من خلال مكتبة على عناوين الشبكة المحلية (مثل بروتوكول اكتشاف خدمة mDNS أو SSDP)
• استخدام فئات على مستوى إطار العمل يمكنها الوصول إلى الشبكة المحلية (مثل NsdManager)

يتطلب نقل البيانات إلى عنوان شبكة محلية ومنه الحصول على إذن بالوصول إلى الشبكة المحلية. يسرد الجدول التالي بعض الحالات الشائعة:

يتم تنفيذ هذه القيود في حزمة الشبكات، وبالتالي تنطبق على جميع واجهات برمجة التطبيقات للشبكات. ويشمل ذلك المقابس التي تم إنشاؤها في الرموز البرمجية الأصلية أو المُدارة، ومكتبات الشبكات مثل Cronet وOkHttp، وأي واجهات برمجة تطبيقات يتم تنفيذها فوقها. ستتطلب محاولة حلّ الخدمات على الشبكة المحلية (أي تلك التي تحتوي على اللاحقة ‎.local) إذنًا بالوصول إلى الشبكة المحلية.

استثناءات للقواعد المذكورة أعلاه:

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

إرشادات للمطوّرين (الموافقة)

لتفعيل قيود الشبكة المحلية، اتّبِع الخطوات التالية:

1. ثبِّت إصدارًا يتضمّن الإصدار التجريبي 3 من 25Q2 أو إصدارًا أحدث على الجهاز.
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>

الأخطاء

ستتم إعادة الأخطاء الناتجة عن هذه القيود إلى المقبس الذي يطلبها كلما استدعى دالة send أو أحد متغيراتها إلى عنوان شبكة محلية.

أمثلة على الأخطاء:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

تعريف الشبكة المحلية

تشير الشبكة المحلية في هذا المشروع إلى شبكة IP تستخدم واجهة شبكة قادرة على البث، مثل Wi-Fi أو إيثرنت، ولكنها تستثني الاتصالات الخلوية (WWAN) أو اتصال عبر شبكة VPN.

في ما يلي الشبكات التي تُعتبر محلية:

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:

• الرابط المحلي
• المسارات المتصلة مباشرةً
• الشبكات الطرفية مثل Thread
• شبكات فرعية متعددة (يُحدَّد لاحقًا)

بالإضافة إلى ذلك، يتم تصنيف كل من عناوين البث المتعدّد الوجهات (224.0.0.0/4 وff00::/8) وعنوان البث العام للإصدار 4 من بروتوكول الإنترنت (255.255.255.255) كعناوين شبكة محلية.

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

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