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

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

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

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

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

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

Android 15 enforced edge-to-edge for apps targeting Android 15 (API level 35), but your app could opt-out by setting R.attr#windowOptOutEdgeToEdgeEnforcement to true. For apps targeting Android 16 (API level 36), R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, and your app can't opt-out of going edge-to-edge.

• If your app targets Android 16 (API level 36) and is running on an Android 15 device, R.attr#windowOptOutEdgeToEdgeEnforcement continues to work.
• If your app targets Android 16 (API level 36) and is running on an Android 16 device, R.attr#windowOptOutEdgeToEdgeEnforcement is disabled.

For testing in Android 16, ensure your app supports edge-to-edge and remove any use of R.attr#windowOptOutEdgeToEdgeEnforcement so that your app also supports edge-to-edge on an Android 15 device. To support edge-to-edge, see the Compose and Views guidance.

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

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

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

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

Apps targeting Android 15 (API level 35) have the elegantTextHeight TextView attribute set to true by default, replacing the compact font with one that is much more readable. You could override this by setting the elegantTextHeight attribute to false.

Android 16 deprecates the elegantTextHeight attribute, and the attribute will be ignored once your app targets Android 16. The "UI fonts" controlled by these APIs are being discontinued, so you should adapt any layouts to ensure consistent and future proof text rendering in Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.

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

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

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

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

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

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

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

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

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

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

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

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

يمكنك أيضًا اختبار هذا السلوك باستخدام اختبار توافق التطبيقات وتفعيل علامة التوافق UNIVERSAL_RESIZABLE_BY_DEFAULT.

التغييرات الشائعة التي قد تؤدي إلى أعطال

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

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

تفاصيل التنفيذ

يتم تجاهل سمات البيان وواجهات برمجة التطبيقات في وقت التشغيل التالية على جميع الأجهزة ذات الشاشات الكبيرة في وضعَي ملء الشاشة والنوافذ المتعددة:

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

يتم تجاهل القيم التالية الخاصة بـ screenOrientation وsetRequestedOrientation() وgetRequestedOrientation():

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

في ما يتعلق بإمكانية تغيير حجم شاشة العرض، ليس هناك أي تأثير على android:resizeableActivity="false" وandroid:minAspectRatio وandroid:maxAspectRatio.

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

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

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

• HEART_RATE_BPM من "خدمات الصحة" على Wear OS
• Sensor.TYPE_HEART_RATE من "مدير أجهزة الاستشعار في Android"
• إزالة heartRateAccuracy وheartRateBpm من ProtoLayout على Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH حيث يجب منح الإذن android.permission.health بدلاً من BODY_SENSORS

إذا كان تطبيقك يستخدم واجهات برمجة التطبيقات هذه، يجب أن يطلب الأذونات الدقيقة ذات الصلة:

• للمراقبة أثناء الاستخدام لمعدّل نبضات القلب أو نسبة تشبّع الأكسجين بالدم أو درجة حرارة الجلد: يجب طلب الإذن الدقيق ضمن android.permissions.health، مثل READ_HEART_RATE بدلاً من BODY_SENSORS.
• للوصول إلى أجهزة الاستشعار في الخلفية، اطلب READ_HEALTH_DATA_IN_BACKGROUND بدلاً من BODY_SENSORS_BACKGROUND.

وهذه الأذونات هي نفسها التي تحمي إمكانية قراءة البيانات من Health Connect، وهو مستودع بيانات Android الخاص ببيانات الصحة واللياقة البدنية والعافية.

تطبيقات الأجهزة الجوّالة

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

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

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

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

كجزء من المعالجة المحسّنة لفقدان الربط، يقدّم نظام التشغيل 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.

الأمان

يتضمّن نظام التشغيل 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, control shifts to the receiving app, allowing developers to opt-in to strict intent resolution using their app manifest.

Two key changes are being implemented:

1. 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.

2. 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:

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:")

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

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

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

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

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

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

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

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

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

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

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

الخصوصية

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

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

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

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

خطة الإصدار

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

التأثير

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

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

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

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

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

استثناءات للقواعد أعلاه:

• إذا كان خادم نظام أسماء النطاقات الخاص بجهاز ما على شبكة محلية، لن تتطلّب حركة بيانات الشبكة من الجهاز أو إليه (على المنفذ 53) إذن الوصول إلى الشبكة المحلية.
• لن تحتاج التطبيقات التي تستخدم أداة Output Switcher كأداة اختيار داخل التطبيق إلى أذونات الشبكة المحلية (سيتم تقديم المزيد من الإرشادات في الربع الرابع من عام 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 أو 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) كعناوين شبكة محلية.

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

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