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

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

يجب نقل البيانات أو إيقاف ميزة "الرجوع التنبؤي"

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

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

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

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

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

سلوك

سلوك

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

يتضمّن نظام التشغيل 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.

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

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

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

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

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

• 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>

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

يتضمّن نظام التشغيل 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

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

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

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

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

2. لا يمكن أن تتطابق الأهداف التي لا تتضمّن إجراءً مع أي فلتر أهداف: يجب ألا يتم حلّ الأهداف التي لا تتضمّن إجراءً محدّدًا إلى أي فلتر أهداف.

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

التأثير

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

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

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

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

يمكن أن تؤدي ميزة "نقل البيانات بشكل أكثر أمانًا" إلى تحسين أمان منظومة Android المتكاملة بشكل كبير من خلال الحد من قدرة التطبيقات الضارة على استغلال الثغرات الأمنية في آلية تحديد الغرض.

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

التنفيذ

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

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

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

الاختبار وتصحيح الأخطاء

عندما يكون التنفيذ نشطًا، من المفترض أن تعمل التطبيقات بشكل صحيح إذا كان التطبيق الذي يستدعي الغرض قد ملأ الغرض بشكل صحيح. ومع ذلك، ستؤدي النوايا المحظورة إلى ظهور رسائل تحذيرية في سجلّ الأخطاء، مثل "Intent does not match component's intent filter:" و"Access blocked:" مع العلامة "PackageManager." يشير ذلك إلى مشكلة محتملة قد تؤثر في التطبيق وتتطلّب الانتباه.

فلتر Logcat:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

الخصوصية

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

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

Devices on the LAN can be accessed by any app that has the INTERNET permission. This makes it easy for apps to connect to local devices but it also has privacy implications such as forming a fingerprint of the user, and being a proxy for location.

The Local Network Protections project aims to protect the user's privacy by gating access to the local network behind a new runtime permission.

Release plan

This change will be deployed between two releases, 25Q2 and TBD respectively. It is imperative that developers follow this guidance for 25Q2 and share feedback because these protections will be enforced at a later Android release. Moreover, they will need to update scenarios which depend on implicit local network access by using the following guidance and prepare for user rejection and revocation of the new permission.

Impact

At the current stage, LNP is an opt-in feature which means only the apps that opt in will be affected. The goal of the opt-in phase is for app developers to understand which parts of their app depend on implicit local network access such that they can prepare to permission guard them for the next release.

Apps will be affected if they access the user's local network using:

• Direct or library use of raw sockets on local network addresses (e.g. mDNS or SSDP service discovery protocol)
• Use of framework level classes that access the local network (e.g. NsdManager)

Traffic to and from a local network address requires local network access permission. The following table lists some common cases:

These restrictions are implemented deep in the networking stack, and thus they apply to all networking APIs. This includes sockets created in native or managed code, networking libraries like Cronet and OkHttp, and any APIs implemented on top of those. Trying to resolve services on the local network (i.e. those with a .local suffix) will require local network permission.

Exceptions to the rules above:

• If a device's DNS server is on a local network, traffic to or from it (at port 53) doesn't require local network access permission.
• Applications using Output Switcher as their in-app picker won't need local network permissions (more guidance to come in 2025Q4).

Developer Guidance (Opt-in)

To opt into local network restrictions, do the following:

1. Flash the device to a build with 25Q2 Beta 3 or later.
2. Install the app to be tested.

3. Toggle the Appcompat flag in adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reboot The device

Now your app's access to the local network is restricted and any attempt to access the local network will lead to socket errors. If you are using APIs that perform local network operations outside of your app process (ex: NsdManager), they won't be impacted during the opt-in phase.

To restore access, you must grant your app permission to NEARBY_WIFI_DEVICES.

1. Ensure the app declares the NEARBY_WIFI_DEVICES permission in its manifest.
2. Go to Settings > Apps > [Application Name] > Permissions > Nearby devices > Allow.

Now your app's access to the local network should be restored and all your scenarios should work as they did prior to opting the app in.

Once enforcement for local network protection begins, here is how the app network traffic will be impacted.

Use the following command to toggle-off the App-Compat flag

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errors

Errors arising from these restrictions will be returned to the calling socket whenever it invokes send or a send variant to a local network address.

Example errors:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Local Network Definition

A local network in this project refers to an IP network that utilizes a broadcast-capable network interface, such as Wi-Fi or Ethernet, but excludes cellular (WWAN) or VPN connections.

The following are considered local networks:

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
• Directly-connected routes
• Stub networks like Thread
• Multiple-subnets (TBD)

Additionally, both multicast addresses (224.0.0.0/4, ff00::/8) and the IPv4 broadcast address (255.255.255.255) are classified as local network addresses.

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

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