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

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

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

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

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

For apps targeting Android 16 (API level 36) or higher, BODY_SENSORS permissions use more granular permissions under android.permissions.health, which Health Connect also uses. As of Android 16, any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND requires the corresponding android.permissions.health permission instead. This affects the following data types, APIs, and foreground service types:

• HEART_RATE_BPM from Health Services on Wear OS
• Sensor.TYPE_HEART_RATE from Android Sensor Manager
• heartRateAccuracy and heartRateBpm from ProtoLayout on Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH where the respective android.permission.health permission is needed in place of BODY_SENSORS

If your app uses these APIs, it should request the respective granular permissions:

• For while-in-use monitoring of Heart Rate, SpO2, or Skin Temperature: request the granular permission under android.permissions.health, such as READ_HEART_RATE instead of BODY_SENSORS.
• For background sensor access: request READ_HEALTH_DATA_IN_BACKGROUND instead of BODY_SENSORS_BACKGROUND.

These permissions are the same as those that guard access to reading data from Health Connect, the Android datastore for health, fitness, and wellness data.

Mobile apps

Mobile apps migrating to use the READ_HEART_RATE and other granular permissions must also declare an activity to display the app's privacy policy. This is the same requirement as Health Connect.

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

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

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

As part of the Improved bond loss handling, Android 16 also introduces 2 new intents to provide apps with greater awareness of bond loss and encryption changes.

Apps targeting Android 16 can now:

• Receive an ACTION_KEY_MISSING intent when remote bond loss is detected, allowing them to provide more informative user feedback and take appropriate actions.
• Receive an ACTION_ENCRYPTION_CHANGE intent whenever encryption status of the link changes. This includes encryption status change, encryption algorithm change, and encryption key size change. Apps must consider the bond restored if the link is successfully encrypted upon receiving ACTION_ENCRYPTION_CHANGE intent later.

Adapting to varying OEM implementations

While Android 16 introduces these new intents, their implementation and broadcasting can vary across different device manufacturers (OEMs). To ensure your app provides a consistent and reliable experience across all devices, developers should design their bond loss handling to gracefully adapt to these potential variations.

We recommend the following app behaviors:

• If the ACTION_KEY_MISSING intent is broadcast:

  The ACL (Asynchronous Connection-Less) link will be disconnected by the system, but the bond information for the device will be retained (as described here).

  Your app should use this intent as the primary signal for bond loss detection and guiding the user to confirm the remote device is in range before initiating device forgetting or re-pairing.

  If a device disconnects after ACTION_KEY_MISSING is received, your app should be cautious about reconnecting, as the device may no longer be bonded with the system.

• If the ACTION_KEY_MISSING intent is NOT broadcast:

  The ACL link will remain connected, and the bond information for the device will be removed by the system, same to behavior in Android 15.

  In this scenario, your app should continue its existing bond loss handling mechanisms as in previous Android releases, to detect and manage bond loss events.

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

All apps targeting Android 16 are now able to unpair bluetooth devices using a public API in CompanionDeviceManager. If a companion device is being managed as a CDM association, then the app can trigger bluetooth bond removal by using the new removeBond(int) API on the associated device. The app can monitor the bond state changes by listening to the bluetooth device broadcast event ACTION_BOND_STATE_CHANGED.

الأمان

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

قفل إصدار MediaStore

For apps targeting Android 16 or higher, MediaStore#getVersion() will now be unique to each app. This eliminates identifying properties from the version string to prevent abuse and usage for fingerprinting techniques. Apps shouldn't make any assumptions around the format of this version. Apps should already handle version changes when using this API and in most cases shouldn't need to change their current behavior, unless the developer has attempted to infer additional information that is beyond the intended scope of this API.

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:

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

الخصوصية

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

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

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

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

خطة الإصدار

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

التأثير

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

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

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

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

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

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

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