كما هو الحال في الإصدارات السابقة، يتضمّن 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.
يجب نقل البيانات أو إيقاف ميزة "الرجوع التنبؤي"
بالنسبة إلى التطبيقات التي تستهدف الإصدار 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 تتكيّف مع أي حجم للشاشة والنافذة، بغض النظر عن اتجاه الجهاز. إنّ نماذج التصميم، مثل حصر الاتجاه وإمكانية تغيير الحجم، أصبحت مقيّدة جدًا في عالم اليوم الذي يضم أجهزة متعددة.
تجاهل القيود المفروضة على الاتجاه وإمكانية تغيير الحجم ونسبة العرض إلى الارتفاع
بالنسبة إلى التطبيقات التي تستهدف الإصدار 16 من نظام التشغيل Android (المستوى 36 لواجهة برمجة التطبيقات)، لن تنطبق قيود الاتجاه وتغيير الحجم ونسبة العرض إلى الارتفاع على الشاشات التي يبلغ عرضها الأصغر 600 وحدة بكسل مستقلة الكثافة (dp) أو أكثر. تملأ التطبيقات نافذة العرض بأكملها، بغض النظر عن نسبة العرض إلى الارتفاع أو الاتجاه المفضّل للمستخدم، ولا يتم استخدام وضع "العمودان الجانبيان".
يقدّم هذا التغيير سلوكًا جديدًا للمنصة. يتجه نظام التشغيل Android نحو نموذج يُتوقّع فيه أن تتكيّف التطبيقات مع مختلف الاتجاهات وأحجام العرض ونِسب العرض إلى الارتفاع. تؤدي القيود، مثل التوجيه الثابت أو إمكانية تغيير الحجم المحدودة، إلى إعاقة قدرة التطبيق على التكيّف. اجعل تطبيقك قابلاً للتكيّف لتقديم أفضل تجربة مستخدم ممكنة.
يمكنك أيضًا اختبار هذا السلوك باستخدام
اختبار توافق التطبيقات وتفعيل
علامة التوافق UNIVERSAL_RESIZABLE_BY_DEFAULT.
التغييرات الشائعة التي قد تؤدي إلى أعطال
قد يؤدي تجاهل قيود الاتجاه وإمكانية تغيير الحجم ونسبة العرض إلى الارتفاع إلى التأثير في واجهة المستخدم لتطبيقك على بعض الأجهزة، خاصةً العناصر المصمَّمة للتنسيقات الصغيرة التي تكون في الوضع العمودي فقط، مثل المشاكل المتعلقة بالتنسيقات الممدودة والرسوم المتحركة والمكوّنات التي تظهر خارج الشاشة. يمكن أن تتسبّب أي افتراضات بشأن نسبة العرض إلى الارتفاع أو الاتجاه في حدوث مشاكل مرئية في تطبيقك. مزيد من المعلومات حول كيفية تجنُّب هذه المشاكل وتحسين السلوك التكيّفي لتطبيقك
يؤدي السماح بتدوير الجهاز إلى إعادة إنشاء المزيد من الأنشطة، ما قد يؤدي إلى فقدان حالة المستخدم إذا لم يتم الاحتفاظ بها بشكل صحيح. تعرَّف على كيفية حفظ حالة واجهة المستخدم بشكل صحيح في مقالة حفظ حالات واجهة المستخدم.
تفاصيل التنفيذ
يتم تجاهل سمات البيان وواجهات برمجة التطبيقات لوقت التشغيل التالية على الأجهزة ذات الشاشات الكبيرة في وضعَي ملء الشاشة والنوافذ المتعددة:
screenOrientationresizableActivityminAspectRatiomaxAspectRatiosetRequestedOrientation()getRequestedOrientation()
يتم تجاهل القيم التالية الخاصة بـ screenOrientation وsetRequestedOrientation() وgetRequestedOrientation():
portraitreversePortraitsensorPortraituserPortraitlandscapereverseLandscapesensorLandscapeuserLandscape
في ما يتعلق بإمكانية تغيير حجم شاشة العرض، ليس هناك أي تأثير على 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 OSFOREGROUND_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 لواجهة برمجة التطبيقات) التغييرات التالية في حزمة بروتوكول البلوتوث لتحسين إمكانية الاتصال بالأجهزة الطرفية.
أهداف جديدة للتعامل مع فقدان الربط والتغييرات في التشفير
كجزء من المعالجة المحسّنة لفقدان الربط، يقدّم نظام التشغيل Android 16 أيضًا هدفَين جديدَين لمنح التطبيقات وعيًا أكبر بفقدان الربط وتغييرات التشفير.
يمكن للتطبيقات التي تستهدف الإصدار 16 من Android الآن تنفيذ ما يلي:
- تلقّي نية
ACTION_KEY_MISSINGعند رصد فقدان الربط عن بُعد ، ما يتيح لهم تقديم ملاحظات أكثر إفادة للمستخدمين واتّخاذ الإجراءات المناسبة - تلقّي نية
ACTION_ENCRYPTION_CHANGEعند تغيير حالة التشفير للرابط ويشمل ذلك تغيير حالة التشفير وتغيير خوارزمية التشفير وتغيير حجم مفتاح التشفير. يجب أن تُعتبر التطبيقات قد أعادت الربط إذا تم تشفير الرابط بنجاح عند تلقّيACTION_ENCRYPTION_CHANGEintent لاحقًا.
التكيّف مع عمليات التنفيذ المختلفة التي يجريها المصنّعون الأصليون للأجهزة
على الرغم من أنّ الإصدار 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.
الأمان
يتضمّن نظام التشغيل Android 16 (المستوى 36 لواجهة برمجة التطبيقات) تغييرات الأمان التالية.
قفل إصدار MediaStore
بالنسبة إلى التطبيقات التي تستهدف الإصدار 16 من نظام التشغيل Android أو الإصدارات الأحدث، سيصبح MediaStore#getVersion()
فريدًا لكل تطبيق. ويؤدي ذلك إلى إزالة السمات التعريفية من سلسلة الإصدار
لمنع إساءة الاستخدام والاستفادة من تقنيات تحديد الهوية. ويجب ألا تفترض التطبيقات
أيّ شيء بشأن تنسيق هذا الإصدار. من المفترض أن تتمكّن التطبيقات من التعامل مع تغييرات الإصدار عند استخدام واجهة برمجة التطبيقات هذه، وفي معظم الحالات، لن تحتاج التطبيقات إلى تغيير سلوكها الحالي، ما لم يحاول المطوّر استنتاج معلومات إضافية تتجاوز النطاق المقصود لواجهة برمجة التطبيقات هذه.
Safer Intents
ميزة "نقل نوايا أكثر أمانًا" هي مبادرة أمان متعدّدة المراحل مصمَّمة لتحسين أمان آلية تحديد الغرض في Android. والهدف من ذلك هو حماية التطبيقات من الإجراءات الضارة من خلال إضافة عمليات تحقّق أثناء معالجة الأهداف وتصفية الأهداف التي لا تستوفي معايير محدّدة.
في Android 15، ركّزت الميزة على تطبيق المرسِل، ولكن مع Android 16، أصبح تطبيق المتلقي هو الذي يتحكّم في العملية، ما يتيح للمطوّرين تفعيل ميزة تحليل الأهداف بدقة باستخدام بيان التطبيق.
سيتم تنفيذ تغييران رئيسيان:
يجب أن تتطابق الأهداف الصريحة (Explicit Intents) مع فلتر Intent الخاص بالمكوِّن المستهدف: إذا كانت الأهداف الصريحة تستهدف مكوِّنًا بشكل صريح، يجب أن تتطابق مع فلتر Intent الخاص بهذا المكوِّن.
لا يمكن أن تتطابق الأهداف التي لا تتضمّن إجراءً مع أي فلتر 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>
مزيد من المعلومات عن العلامات المتوافقة:
| اسم العلامة | الوصف |
|---|---|
| enforceIntentFilter | فرض مطابقة أكثر صرامة لرسائل Intent الواردة |
| لا شيء | يؤدي ذلك إلى إيقاف جميع قواعد المطابقة الخاصة للطلبات الواردة. عند تحديد علامات متعدّدة، يتم حل القيم المتعارضة من خلال منح الأولوية للعلامة "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 表面，在生产 build 中，已废弃或仅用于 GPU 开发的 Mali GPU IOCTL 已被屏蔽。此外，用于 GPU 性能分析的 IOCTL 已限制为 shell 进程或可调试的应用。如需详细了解平台级政策，请参阅 SAC 更新。
此更改适用于使用 Mali GPU 的 Pixel 设备（Pixel 6-9）。Arm 已在其 r54p2 版本的 Documentation/ioctl-categories.rst 中提供了 IOCTL 的官方分类。此列表将在未来的驱动程序版本中继续维护。
此项变更不会影响受支持的图形 API（包括 Vulkan 和 OpenGL），预计也不会影响开发者或现有应用。 Streamline Performance Analyzer 和 Android GPU 检查器等 GPU 性能剖析工具不会受到影响。
测试
如果您看到类似如下所示的 SELinux 拒绝，则说明您的应用可能受到了此变更的影响：
06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc: denied { ioctl }
for path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts
如果您的应用需要使用被屏蔽的 IOCTL，请提交 bug 并将其分配给 android-partner-security@google.com。
常见问题解答
此政策变更是否适用于所有原始设备制造商 (OEM)？ 此变更将采用选择启用模式，但任何想要使用此强化方法的 OEM 都可以使用。如需了解如何实现此变更，请参阅实现文档。
是否必须在 OEM 代码库中进行更改才能实现此功能，还是默认随新的 AOSP 版本提供？ 平台级变更将默认随新的 AOSP 版本一起发布。如果供应商想要应用此变更，可以在其代码库中选择启用此变更。
SoC 是否负责使 IOCTL 列表保持最新状态？例如，如果我的设备使用 ARM Mali GPU，我是否需要就任何更改与 ARM 联系？ 各个 SoC 必须在驱动程序发布后根据设备更新其 IOCTL 列表。 例如，ARM 会在驱动程序更新时更新其已发布的 IOCTL 列表。 不过，OEM 应确保在 SEPolicy 中纳入这些更新，并根据需要将任何选定的自定义 IOCTL 添加到列表中。
此变更是否会自动应用于所有在售 Pixel 设备，还是需要用户执行操作来切换某些设置才能应用此变更？ 此变更适用于所有使用 Mali GPU 的 Pixel 在售设备（Pixel 6-9）。用户无需采取任何行动即可应用此变更。
使用此政策会影响内核驱动程序的性能吗？ 我们使用 GFXBench 在 Mali GPU 上测试了此政策，未发现 GPU 性能有任何可衡量的变化。
IOCTL 列表是否需要与当前的用户空间和内核驱动程序版本保持一致？ 是的，允许的 IOCTL 列表必须与用户空间和内核驱动程序支持的 IOCTL 同步。如果用户空间或内核驱动程序中的 IOCTL 发生更新，则必须更新 SEPolicy IOCTL 列表以保持一致。
ARM 已将 IOCTL 分类为“受限”/“检测”，但我们希望在生产用例中使用其中一些 IOCTL，并拒绝其他 IOCTL。 各个 OEM/SoC 负责根据其用户空间 Mali 库的配置来决定如何对其使用的 IOCTL 进行分类。ARM 的列表可用于帮助确定这些值，但每个 OEM/SoC 的使用情形可能有所不同。
الخصوصية
يتضمّن نظام التشغيل Android 16 (المستوى 36 لواجهة برمجة التطبيقات) تغييرات الخصوصية التالية.
إذن الوصول إلى الشبكة المحلية
يمكن لأي تطبيق لديه إذن INTERNET الوصول إلى الأجهزة على الشبكة المحلية.
يسهّل ذلك على التطبيقات الاتصال بالأجهزة المحلية، ولكن له أيضًا آثار على الخصوصية، مثل إنشاء بصمة رقمية للمستخدم، والعمل كخادم وكيل للموقع الجغرافي.
يهدف مشروع "حماية الشبكة المحلية" إلى حماية خصوصية المستخدم من خلال حصر الوصول إلى الشبكة المحلية بإذن جديد أثناء التشغيل.
خطة الإصدار
سيتم طرح هذا التغيير بين إصدارَين، 25Q2 و26Q2 على التوالي. من الضروري أن يلتزم المطوّرون بهذه الإرشادات في الربع الثاني من عام 2025 وأن يشاركوا ملاحظاتهم، لأنّ هذه الحمايات سيتم فرضها في إصدار Android لاحق. بالإضافة إلى ذلك، عليهم تعديل السيناريوهات التي تعتمد على الوصول الضمني إلى الشبكة المحلية باتّباع الإرشادات التالية والاستعداد لرفض المستخدمين وإلغاء الإذن الجديد.
التأثير
في المرحلة الحالية، ميزة "الشبكة المحلية فقط" هي ميزة اختيارية، ما يعني أنّ التطبيقات التي تفعّلها فقط ستتأثر بها. والهدف من مرحلة الموافقة هو أن يفهم مطوّرو التطبيقات الأجزاء التي تعتمد على الوصول الضمني إلى الشبكة المحلية، حتى يتمكّنوا من إعدادها لتكون محمية بإذن في الإصدار التالي.
ستتأثر التطبيقات إذا كانت تصل إلى الشبكة المحلية للمستخدم باستخدام:
- الاستخدام المباشر أو استخدام المكتبة للمقابس الأولية على عناوين الشبكة المحلية (مثل بروتوكول mDNS أو SSDP لاكتشاف الخدمات)
- استخدام فئات على مستوى إطار العمل يمكنها الوصول إلى الشبكة المحلية (مثل NsdManager)
تتطلّب حركة البيانات من عنوان شبكة محلية وإليه إذنًا بالوصول إلى الشبكة المحلية. يسرد الجدول التالي بعض الحالات الشائعة:
| عمليات الشبكة المنخفضة المستوى في التطبيق | يجب منح إذن الوصول إلى الشبكة المحلية |
|---|---|
| إجراء اتصال TCP صادر | نعم |
| قبول اتصالات TCP الواردة | نعم |
| إرسال بث أحادي أو بث متعدّد أو بث عادي عبر UDP | نعم |
| تلقّي بث أحادي أو متعدد أو عادي وارد عبر UDP | نعم |
يتم تنفيذ هذه القيود في أعماق حزمة الشبكات، وبالتالي تنطبق على جميع واجهات برمجة التطبيقات المتعلقة بالشبكات. ويشمل ذلك المقابس التي تم إنشاؤها في الرموز البرمجية الأصلية أو المُدارة، ومكتبات الشبكات مثل Cronet وOkHttp، وأي واجهات برمجة تطبيقات تم تنفيذها فوق هذه المكتبات. ستتطلّب محاولة حلّ الخدمات على الشبكة المحلية (أي تلك التي تتضمّن اللاحقة .local) إذنًا بالوصول إلى الشبكة المحلية.
استثناءات للقواعد أعلاه:
- إذا كان خادم DNS الخاص بجهاز معيّن متصلاً بشبكة محلية، لن يتطلّب نقل البيانات من الجهاز أو إليه (على المنفذ 53) إذنًا بالوصول إلى الشبكة المحلية.
- لن تحتاج التطبيقات التي تستخدم أداة Output Switcher كأداة اختيار داخل التطبيق إلى أذونات الوصول إلى الشبكة المحلية (ستتوفّر المزيد من الإرشادات في الربع الرابع من عام 2025).
إرشادات للمطوّرين (تفعيل)
لإيقاف القيود على الشبكة المحلية، اتّبِع الخطوات التالية:
- تثبيت إصدار يتضمّن الإصدار التجريبي 3 من 25Q2 أو إصدار أحدث على الجهاز
- ثبِّت التطبيق الذي تريد اختباره.
بدِّل علامة Appcompat في adb:
adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>إعادة تشغيل الجهاز
سيتم الآن تقييد وصول تطبيقك إلى الشبكة المحلية، وسيؤدي أي محاولة للوصول إلى الشبكة المحلية إلى حدوث أخطاء في المقبس. إذا كنت تستخدم واجهات برمجة تطبيقات تنفّذ عمليات على الشبكة المحلية خارج عملية تطبيقك (مثل NsdManager)، لن تتأثّر هذه العمليات خلال مرحلة الموافقة.
لاستعادة إمكانية الوصول، يجب منح تطبيقك الإذن بالوصول إلى NEARBY_WIFI_DEVICES.
- تأكَّد من أنّ التطبيق يعلن عن إذن
NEARBY_WIFI_DEVICESفي بيان التطبيق. - انتقِل إلى الإعدادات > التطبيقات > [اسم التطبيق] > الأذونات > الأجهزة القريبة > السماح.
من المفترض الآن أن يكون قد تم استعادة إذن وصول تطبيقك إلى الشبكة المحلية، وأن تعمل جميع السيناريوهات كما كانت قبل منح التطبيق الإذن.
بعد بدء فرض حماية الشبكة المحلية، إليك تأثير ذلك في عدد الزيارات الواردة إلى شبكة التطبيق.
| الإذن | Outbound LAN Request | طلب الإنترنت الصادر/الوارد | طلب شبكة LAN وارد |
|---|---|---|---|
| تم منح الأذونات | Works | Works | Works |
| لم يتم المنح | الإخفاقات | Works | الإخفاقات |
استخدِم الأمر التالي لإيقاف علامة 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:
- Link-local
- المسارات المرتبطة مباشرةً
- شبكات الأجهزة الوهمية، مثل Thread
- الشبكات الفرعية المتعددة (يُحدَّد لاحقًا)
بالإضافة إلى ذلك، يتم تصنيف كل من عناوين البث المتعدد (224.0.0.0/4 وff00::/8) وعنوان البث IPv4 (255.255.255.255) كعناوين شبكة محلية.
الصور التي يملكها التطبيق
عندما يطلب تطبيق يستهدف الإصدار 36 من حزمة SDK أو إصدارًا أحدث على الأجهزة التي تعمل بالإصدار 16 من نظام التشغيل Android أو إصدارًا أحدث أذونات الوصول إلى الصور والفيديوهات، سيظهر للمستخدمين الذين يختارون حصر الوصول إلى الوسائط المحدّدة أي صور يملكها التطبيق تم اختيارها مسبقًا في أداة اختيار الصور. يمكن للمستخدمين إلغاء اختيار أي من هذه العناصر المحدّدة مسبقًا، ما سيؤدي إلى إبطال إذن وصول التطبيق إلى هذه الصور والفيديوهات.