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

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

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

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

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

إيقاف مشاركة البيانات الشخصية في وضع "العرض حتى حافة الشاشة"

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

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

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

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

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

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

الصورة المتحركة لإيماءة الرجوع التوقّعية إلى الشاشة الرئيسية

الصورة المتحركة التنبؤية بين الأنشطة

الصورة المتحركة التنبؤية التي تظهر عند التنقّل بين المهام:

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

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

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

سلوك

elegantTextHeight للتطبيقات التي تستهدف الإصدار 14 من نظام التشغيل Android (المستوى 34 لواجهة برمجة التطبيقات) والإصدارات الأقدم، أو للتطبيقات التي تستهدف الإصدار 15 من نظام التشغيل Android (المستوى 35 لواجهة برمجة التطبيقات) والتي تم فيها تجاهل الإعداد التلقائي من خلال ضبط السمة elegantTextHeight على false.

سلوك

elegantTextHeight للتطبيقات التي تستهدف الإصدار 16 من نظام التشغيل Android (المستوى 36 لواجهة برمجة التطبيقات)، أو للتطبيقات التي تستهدف الإصدار 15 من نظام التشغيل Android (المستوى 35 لواجهة برمجة التطبيقات) والتي لم تتجاوز الإعداد التلقائي من خلال ضبط السمة elegantTextHeight على false.

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

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

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

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

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

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

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

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

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

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

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

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

ملاحظة مهمة: إنّ إيقاف الميزة مؤقت ولن ينطبق عند استهداف المستوى 37 لواجهة برمجة التطبيقات في إصدار Android مستقبلي. أي بالنسبة إلى التطبيقات التي تستهدف المستوى 37 لواجهة برمجة التطبيقات، يتم تجاهُل قيود الاتجاه وإمكانية تغيير الحجم ونسبة العرض إلى الارتفاع على شاشات العرض التي يبلغ حجمها sw600dp على الأقل.

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

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

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

对于以 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_BPM Wear OS 上的健康服务
• Sensor.TYPE_HEART_RATE 来自 Android Sensor Manager
• heartRateAccuracy 和 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 以显示应用的隐私权政策。这与健康数据共享的要求相同。

**重要提示：** 如果未能为移动应用提供理由，系统将撤消相应 权限。

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

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

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

作为改进了对键值对丢失的处理的一部分，Android 16 还引入了 2 个新 intent，以便应用更好地了解键值对丢失和加密更改。

以 Android 16 为目标平台的应用现在可以：

• 在检测到远程键盘连接丢失时接收 ACTION_KEY_MISSING intent，以便提供更具信息量的用户反馈并采取适当的措施。
• 每当链接的加密状态发生变化时，都会收到 ACTION_ENCRYPTION_CHANGE intent。这包括加密状态更改、加密算法更改和加密密钥大小更改。如果应用在稍后收到 ACTION_ENCRYPTION_CHANGE intent 时成功加密了链接，则必须将该绑定视为已恢复。

适应不同的 OEM 实现

虽然 Android 16 引入了这些新 intent，但其实现和广播可能会因不同的设备制造商 (OEM) 而异。为了确保您的应用在所有设备上都能提供一致且可靠的体验，开发者应设计其绑定丢失处理机制，以妥善适应这些潜在的变化。

我们建议您采用以下应用行为：

• 如果广播 ACTION_KEY_MISSING intent：

  系统会断开 ACL（异步无连接）链接，但会保留设备的配对信息（如此处所述）。

  您的应用应将此 intent 用作检测配对丢失的主要信号，并在发起设备忘记或重新配对之前引导用户确认远程设备是否在范围内。

  如果设备在收到 ACTION_KEY_MISSING 后断开连接，您的应用应谨慎重新连接，因为设备可能已不再与系统绑定。

• 如果未广播 ACTION_KEY_MISSING intent：

  ACL 链接将保持连接状态，系统会移除设备的配对信息，与 Android 15 中的行为相同。

  在这种情况下，您的应用应继续使用与之前的 Android 版本相同的现有配对丢失处理机制，以检测和管理配对丢失事件。

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

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

ملاحظة: يمكن تحديد السمة في العلامة <application> بالإضافة إلى علامات المكوّنات، مثل <activity> و<activity-alias> و<receiver> و<service> و<provider>، ويمكن استخدام السمة في المكوِّن لتجاوز ما هو موجود في العلامة <application>

مزيد من المعلومات حول العلامات المتوافقة:

اسم العلامة	الوصف
enforceIntentFilter	يفرض مطابقة أكثر صرامة للأهداف الواردة
none	يوقف جميع قواعد المطابقة الخاصة للأهداف الواردة. عند تحديد علامات متعدّدة، يتم حلّ القيم المتعارضة من خلال منح الأولوية للعلامة "none"
allowNullAction	يخفّف قواعد المطابقة للسماح بمطابقة الأهداف بدون إجراء. يجب استخدام هذه العلامة مع "enforceIntentFilter" لتحقيق سلوك معيّن

الاختبار وتحديد المشاكل وحلّها

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

يتم تطبيق هذا التغيير على أجهزة 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

إذا كان تطبيقك بحاجة إلى استخدام واجهات IOCTL المحظورة، يُرجى الإبلاغ عن الخطأ وتعيينه إلى [e-mail].

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

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

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

3. هل وحدات النظام على شريحة (SoC) مسؤولة عن إبقاء قائمة واجهات 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 التي يتيحها كل من مساحة المستخدم وبرامج تشغيل النواة. إذا تم تعديل واجهات IOCTL في مساحة المستخدم أو برنامج تشغيل النواة، يجب تعديل قائمة واجهات IOCTL في سياسة SELinux لتتطابق معها.

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

الخصوصية

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

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

具有 INTERNET 权限的任何应用都可以访问局域网中的设备。 这使得应用可以轻松连接到本地设备，但也存在隐私方面的影响，例如形成用户指纹，以及成为位置信息的代理。

本地网络保护项目旨在通过在新的运行时权限后限制对本地网络的访问，来保护用户的隐私。

发布计划

这项变更将分别在 25Q2 和 26Q2 这两个版本之间部署。 开发者必须遵循 25Q2 的相关指南并分享反馈，因为这些保护措施将在后续 Android 版本中强制执行。此外，他们还需要按照以下指南更新依赖于隐式本地网络访问权限的场景，并为用户拒绝和撤消新权限做好准备。

影响

在当前阶段，LNP 是一项选择启用功能，这意味着只有选择启用的应用会受到影响。选择启用阶段的目标是让应用开发者了解应用的哪些部分依赖于隐式本地网络访问权限，以便他们为下一个版本做好权限保护准备。

如果应用使用以下方式访问用户的本地网络，则会受到影响：

• 直接或通过库使用本地网络地址（例如 mDNS 或 SSDP 服务发现协议）上的原始套接字
• 使用可访问本地网络的框架级类（例如 NsdManager）

向本地网络地址发送流量和从本地网络地址接收流量需要本地网络访问权限。下表列出了一些常见情况：

应用低级层网络操作	需要本地网络权限
建立出站 TCP 连接	是
接受传入的 TCP 连接	是
发送 UDP 单播、多播、广播	是
接收传入的 UDP 单播、多播、广播	是

这些限制是在网络堆栈深处实现的，因此适用于所有网络 API。这包括在原生代码或受管理代码中创建的套接字、Cronet 和 OkHttp 等网络库，以及基于这些库实现的任何 API。尝试解析本地网络上的服务（即带有 .local 后缀的服务）将需要本地网络权限。

注意： 源自需要本地网络访问权限的 Android WebView 的流量将继承宿主应用的权限状态

上述规则的例外情况：

• 如果设备的 DNS 服务器位于本地网络上，则进出该服务器（位于端口 53）的流量不需要本地网络访问权限。
• 使用输出切换器作为其应用内选择器的应用将不需要本地网络权限（更多指南将在 2025 年第 4 季度发布）。

注意： 许多媒体投屏场景都依赖于对本地网络的访问权限，因此会受到此变更的影响。不过，并非所有提供投屏功能的应用都需要请求新权限。未来将提供 API 和指南，以应对投屏场景，这些内容将在 25Q4 中提供。

开发者指南（选择启用）

如需选择启用本地网络限制，请执行以下操作：

1. 将设备刷写到 25Q2 Beta 3 或更高版本的 build。
2. 安装要测试的应用。

3. 在 adb 中切换 Appcompat 标志：

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. 重启设备

现在，您的应用对本地网络的访问受到限制，任何访问本地网络的尝试都会导致套接字错误。如果您使用的 API 在应用进程之外执行本地网络操作（例如：NsdManager），在选择启用阶段，这些 API 不会受到影响。

如需恢复访问权限，您必须向应用授予 NEARBY_WIFI_DEVICES 权限。

1. 确保应用在其清单中声明了 NEARBY_WIFI_DEVICES 权限。
2. 依次前往设置 > 应用 > [应用名称] > 权限 > 附近的设备 > 允许。

注意： 在未来的 Android 版本中，此功能将受“附近的设备”权限组中的新权限保护

现在，应用对本地网络的访问权限应该已恢复，并且所有场景都应像选择启用应用之前一样正常运行。

本地网络保护功能开始强制执行后，应用的网络流量将受到以下影响。

权限	出站 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) 也被归类为本地网络地址。

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

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