كما هو الحال في الإصدارات السابقة، يتضمّن Android 16 تغييرات في السلوك قد تؤثّر في تطبيقك. تنطبق تغييرات السلوك التالية حصريًا على التطبيقات التي تستهدف الإصدار 16 من نظام التشغيل Android أو الإصدارات الأحدث. إذا كان تطبيقك يستهدف الإصدار 16 من نظام التشغيل Android أو الإصدارات الأحدث، عليك تعديل تطبيقك ليتوافق مع هذه السلوكيات، حيثما ينطبق ذلك.
احرص أيضًا على مراجعة قائمة التغييرات في السلوك التي تؤثر في جميع التطبيقات
التي تعمل على Android 16 بغض النظر عن targetSdkVersion لتطبيقك.
تجربة المستخدم وواجهة مستخدم النظام
يتضمّن نظام التشغيل Android 16 (المستوى 36 من واجهة برمجة التطبيقات) التغييرات التالية التي تهدف إلى توفير تجربة مستخدم أكثر اتساقًا وسهولة.
إيقاف مشاركة البيانات الشخصية في وضع "العرض حتى حافة الشاشة"
فرض ميزة "العرض حتى حافة الشاشة" في Android 15 على التطبيقات التي تستهدف الإصدار 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.
يجب نقل البيانات أو إيقاف ميزة "الرجوع التنبؤي"
对于以 Android 16（API 级别 36）或更高版本为目标平台且在搭载 Android 16 或更高版本的设备上运行的应用，预测性返回系统动画（返回主屏幕、跨任务和跨 activity）默认处于启用状态。此外，系统不再调用 onBackPressed，也不再调度 KeyEvent.KEYCODE_BACK。
如果您的应用会拦截返回事件，但您尚未迁移到预测性返回，请更新应用以使用受支持的返回导航 API，或者暂时选择停用，方法是在应用的 AndroidManifest.xml 文件的 <application> 或 <activity> 标记中将 android:enableOnBackInvokedCallback 属性设置为 false。
إيقاف واجهات برمجة التطبيقات الخاصة بالخطوط الأنيقة نهائيًا
في التطبيقات التي تستهدف الإصدار 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 لواجهة برمجة التطبيقات)، يتضمّن Android 16 تغييرات في طريقة إدارة النظام لقيود الاتجاه وتغيير الحجم ونسبة العرض إلى الارتفاع. على الشاشات التي يبلغ عرضها الأصغر 600 وحدة بكسل مستقلة عن الكثافة أو أكثر، لا تنطبق القيود. تتضمّن التطبيقات أيضًا نافذة العرض بأكملها، بغض النظر عن نسبة العرض إلى الارتفاع أو اتجاه الشاشة المفضّل لدى المستخدم، ولا يتم استخدام تنسيق العمودين الجانبيين.
يقدّم هذا التغيير سلوكًا جديدًا للمنصة. يتجه نظام التشغيل 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
The Safer Intents feature is a multi-phase security initiative designed to improve the security of Android's intent resolution mechanism. The goal is to protect apps from malicious actions by adding checks during intent processing and filtering intents that don't meet specific criteria.
In Android 15 the feature focused on the sending app, now with Android 16, shifts control to the receiving app, allowing developers to opt-in to strict intent resolution using their app manifest.
Two key changes are being implemented:
Explicit Intents Must Match the Target Component's Intent Filter: If an intent explicitly targets a component, it should match that component's intent filter.
Intents Without an Action Cannot Match any Intent Filter: Intents that don't have an action specified shouldn't be resolved to any intent filter.
These changes only apply when multiple apps are involved and don't affect intent handling within a single app.
Impact
The opt-in nature means that developers must explicitly enable it in their app manifest for it to take effect. As a result, the feature's impact will be limited to apps whose developers:
- Are aware of the Safer Intents feature and its benefits.
- Actively choose to incorporate stricter intent handling practices into their apps.
This opt-in approach minimizes the risk of breaking existing apps that may rely on the current less-secure intent resolution behavior.
While the initial impact in Android 16 may be limited, the Safer Intents initiative has a roadmap for broader impact in future Android releases. The plan is to eventually make strict intent resolution the default behavior.
The Safer Intents feature has the potential to significantly enhance the security of the Android ecosystem by making it more difficult for malicious apps to exploit vulnerabilities in the intent resolution mechanism.
However, the transition to opt-out and mandatory enforcement must be carefully managed to address potential compatibility issues with existing apps.
Implementation
Developers need to explicitly enable stricter intent matching using the
intentMatchingFlags attribute in their app manifest.
Here is an example where the feature is opt-in for the entire app,
but disabled/opt-out on a receiver:
<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>
More on the supported flags:
| Flag Name | Description |
|---|---|
| enforceIntentFilter | Enforces stricter matching for incoming intents |
| none | Disables all special matching rules for incoming intents. When specifying multiple flags, conflicting values are resolved by giving precedence to the "none" flag |
| allowNullAction | Relaxes the matching rules to allow intents without an action to match. This flag to be used in conjunction with "enforceIntentFilter" to achieve a specific behavior |
Testing and Debugging
When the enforcement is active, apps should function correctly if the intent
caller has properly populated the intent.
However, blocked intents will trigger warning log messages like
"Intent does not match component's intent filter:" and "Access blocked:"
with the tag "PackageManager."
This indicates a potential issue that could impact the app and requires
attention.
Logcat filter:
tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")
الخصوصية
يتضمّن نظام التشغيل Android 16 (المستوى 36 لواجهة برمجة التطبيقات) تغييرات الخصوصية التالية.
إذن الوصول إلى الشبكة المحلية
يمكن لأي تطبيق لديه إذن INTERNET الوصول إلى الأجهزة على الشبكة المحلية.
يسهّل ذلك على التطبيقات الاتصال بالأجهزة المحلية، ولكن له أيضًا آثار على الخصوصية، مثل إنشاء بصمة للمستخدم، والعمل كخادم وكيل للموقع الجغرافي.
يهدف مشروع "حماية الشبكة المحلية" إلى حماية خصوصية المستخدم من خلال حصر الوصول إلى الشبكة المحلية بإذن جديد أثناء التشغيل.
خطة الإصدار
سيتم طرح هذا التغيير بين إصدارَين، هما 25Q2 وTBD على التوالي. من الضروري أن يلتزم المطوّرون بهذه الإرشادات في الربع الثاني من عام 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 أو Ethernet، ولكنها تستبعد الاتصالات عبر شبكة الجوّال (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) كعناوين شبكة محلية.
الصور التي يملكها التطبيق
当面向 SDK 36 或更高版本的应用在搭载 Android 16 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。