أذونات وقت التشغيل

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

• أذونات وقت التثبيت

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

• أذونات التشغيل

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

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

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

الأذونات المتأثرة

يتطلب الإصدار Android 6.0 والإصدارات الأحدث أذونات خطيرة لاستخدام نموذج أذونات وقت التشغيل. الأذونات الخطيرة هي أذونات عالية الخطورة (مثل READ_CALENDAR) التي تمنح التطبيقات التي تطلبها إذنًا بالوصول إلى بيانات المستخدم الخاصة أو التحكّم في الجهاز، ما يمكن أن يؤثر سلبًا في المستخدم. للاطّلاع على قائمة بالأذونات الخطيرة، يمكنك تنفيذ الأمر التالي:

adb shell pm list permissions -g -d

لا يغيّر الإصدار 6.0 من نظام التشغيل Android والإصدارات الأحدث سلوك أذونات الاستخدام العادي. وهذه هي جميع الأذونات غير الخطيرة، بما في ذلك الأذونات العادية وأذونات النظام وأذونات التوقيع. الأذونات العادية هي أذونات ذات مخاطر أقل (مثل SET_WALLPAPER) تمنح التطبيقات التي تطلبها إمكانية الوصول إلى ميزات معزولة على مستوى التطبيق مع الحد الأدنى من المخاطر على التطبيقات الأخرى أو النظام أو المستخدم. كما هو الحال في الإصدار 5.1 من Android والإصدارات الأقدم، يمنح النظام تلقائيًا الأذونات العادية للتطبيق الذي يطلبها عند التثبيت ولا يطلب من المستخدم الموافقة. للاطّلاع على تفاصيل عن الأذونات، يُرجى الاطّلاع على مستندات عنصر<permission>.

القيود الصارمة وغير الصارمة في Android 10

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

• (القيود الصارمة) لا يمكن منح التطبيقات أذونات ليست في القائمة المسموح بها.
• (القيود غير الصارمة) تعمل التطبيقات التي لم يتم إدراجها في القائمة المسموح بها وفقًا للإذن المحدد الذي تطلبه. ويتم وصف هذا السلوك في مستندات المعلومات العامة الخاصة بالإذن المطلوب.

عند تثبيت أحد التطبيقات، قد يختار القائم بالتثبيت (مثل "متجر Google Play")عدم إدراج الأذونات المحظورة للتطبيق في القائمة المسموح بها. يتم فرض قيود على الأذونات من خلال النظام الأساسي ولا يمكن منحها إلا إذا كان التطبيق يستوفي معايير خاصة وفقًا لسياسة النظام الأساسي. تشمل أمثلة أنواع الأذونات التي تم فرض قيود صارمة عليها أذونات الرسائل القصيرة وسجلّ المكالمات.

تتم إضافة التطبيقات إلى القائمة المسموح بها أثناء التثبيت، وفي الحالات التالية:

• تم تثبيت تطبيق أثناء ترقية نظام التشغيل Android من الإصدار 9 إلى الإصدار 10.
• تم منح الإذن مسبقًا أو تم تثبيت التطبيق مسبقًا.
• يجب الحصول على إذن لدور محدّد مسبقًا لإضافته إلى القائمة المسموح بها للإذن.
• تضع أداة التثبيت (مثل "متجر Google Play") علامة على الإذن بأنّه مُدرَج في القائمة المسموح بها.

لا يمكن للمستخدمين إضافة الأذونات يدويًا إلى القائمة المسموح بها.

المتطلبات

ينطبق نموذج أذونات التشغيل على جميع التطبيقات، بما في ذلك التطبيقات المُثبَّتة مسبقًا والتطبيقات التي يتم إرسالها إلى الجهاز كجزء من عملية الإعداد. تشمل متطلبات برامج التطبيقات ما يلي:

• يجب أن يكون نموذج أذونات وقت التشغيل متسقًا على جميع الأجهزة التي تعمل بالإصدار 6.0 من نظام التشغيل Android والإصدارات الأحدث. ويتم فرض ذلك من خلال اختبارات مجموعة أدوات اختبار التوافق مع Android (CTS).
• يجب أن تطلب التطبيقات من المستخدمين منح أذونات التطبيق أثناء التشغيل. لمعرفة التفاصيل، يُرجى الاطّلاع على مقالة تحديث التطبيقات. قد يتم منح استثناءات محدودة للتطبيقات والمعالجات التلقائية التي توفّر وظائف الجهاز الأساسية اللازمة لعمل الجهاز على النحو المتوقّع. (على سبيل المثال، قد يكون لتطبيق "أداة الاتصال" التلقائي على الجهاز لمعالجة ACTION_CALL إذن الوصول إلى "الهاتف"). لمعرفة التفاصيل، يُرجى الاطّلاع على إنشاء استثناءات.
• التطبيقات المحمَّلة مسبقًا التي تمتلك أذونات خطيرة يجب أن تستهدف المستوى 23 لواجهة برمجة التطبيقات وأن تحافظ على نموذج أذونات وقت التشغيل. وهذا يعني أنّ عملية تفاعل المستخدم مع واجهة المستخدم أثناء تثبيت التطبيق يجب ألا تختلف عن عملية تنفيذ AOSP لسمة PermissionController، وأن يتمكّن المستخدمون من إلغاء الأذونات الخطيرة للتطبيقات المثبَّتة مسبقًا، وما إلى ذلك.
• يجب أن تستخدم التطبيقات التي لا تتضمّن واجهة مستخدم نشاطًا لطلب الأذونات أو لمشاركة ملف تعريف شخصي مع تطبيق آخر لديه الأذونات اللازمة. لمعرفة التفاصيل، يُرجى الاطّلاع على التطبيقات التي لا تتضمّن واجهة مستخدم.

نقل الأذونات

تظل الأذونات الممنوحة للتطبيقات على نظام التشغيل Android 5.x مفروضة بعد التحديث إلى Android 6.0 أو إصدار أحدث، ولكن يمكن للمستخدمين إلغاء هذه الأذونات في أي وقت.

في تحديث Android 9 إلى 10، تتم إضافة جميع الأذونات التي تم فرض قيود صارمة عليها إلى القائمة المسموح بها. للاطّلاع على تفاصيل حول تنفيذ أذونات تقسيم المقدّمة/الخلفية، يُرجى الاطّلاع على تغيير الخصوصية في Android 10، بدءًا من طلب تحديد الموقع الجغرافي في الخلفية.

التكامل

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

تحديث التطبيقات

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

التطبيقات المحمَّلة مسبقًا

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

في الإصدارات من Android 6.0 إلى 9، يتم منح بعض الأذونات أثناء عملية التثبيت. ومع ذلك، اعتبارًا من الإصدار 10، أصبحت عملية التثبيت (التي ينفّذها تطبيق Package Installer) وظيفة منفصلة عن منح الأذونات (في تطبيق Permission Controller).

التطبيقات التي لا تتضمّن واجهة مستخدم

يمكن للأنشطة فقط طلب الأذونات. لا يمكن للخدمات طلب الأذونات مباشرةً.

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

والهدف من ذلك هو تجنُّب إرباك المستخدمين بطلبات الأذونات التي تظهر خارج السياق.

تخصيص واجهة مستخدم PackageInstaller

يمكنك تخصيص مظهر واجهة مستخدم "الأذونات" من خلال تعديل مظاهر الجهاز التلقائية (Theme.DeviceDefault.Settings وTheme.DeviceDefault.Light.Dialog.NoActionBar) التي يستخدمها PackageInstaller، إذا أردت ذلك. ومع ذلك، بما أنّ الاتساق مهم جدًا لمطوّري التطبيقات، لا يمكنك تخصيص موضع واجهة مستخدم "أذونات التطبيق" ومكانها وقواعد ظهورها.

لتضمين سلاسل بلغات إضافية، يمكنك المساهمة في تطوير السلاسل في AOSP.

إنشاء استثناءات

يمكنك منح الأذونات مسبقًا للتطبيقات التي تكون معالِجات أو موفّرين تلقائيين لوظائف نظام التشغيل الأساسية باستخدام فئة DefaultPermissionGrantPolicy.java في PackageManager. أمثلة:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone

SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

تحديد أذونات مخصّصة

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

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

• يمكنك إضافة أذونات جديدة إلى مجموعة حالية، ولكن لا يمكنك تعديل ملف ربط AOSP للأذونات الخطيرة ومجموعات الأذونات الخطيرة. (بمعنى آخر، لا يمكنك إزالة إذن من مجموعة ومنحه لمجموعة أخرى).
• يمكنك إضافة مجموعات أذونات جديدة في التطبيقات المثبّتة على الجهاز، ولكن لا يمكنك إضافة مجموعات أذونات جديدة في بيان المنصة.

أذونات الاختبار

يتضمّن Android اختبارات مجموعة أدوات اختبار التوافق (CTS) التي تتحقّق من ربط الأذونات الفردية بالمجموعات الصحيحة. ويجب اجتياز هذه الاختبارات لضمان التوافق مع مجموعة أدوات اختبار التوافق (CTS) في الإصدار 6.0 من نظام Android والإصدارات الأحدث.

إبطال الأذونات

في الإصدار 13 من Android والإصدارات الأحدث، يمكنك إلغاء أذونات التشغيل التي منحتَها باستخدام Context.revokeSelfPermissionsOnKill(). يحدث الإبطال بشكل غير متزامن ويتم تفعيله عندما يكون من الآمن إجراء ذلك بدون تعطيل المستخدم. عند بدء عملية الإبطال، يتم إنهاء جميع العمليات التي تعمل في المعرّف الفريد للمكالمة.

من المهم معرفة أنّ إلغاء إذن واحد قد لا يظهر في واجهة مستخدم الإعدادات التي تتعامل مع الأذونات حسب المجموعة. تظهر مجموعة الأذونات عادةً على أنّها ممنوحة ما دام قد تم منح إذن واحد على الأقل في تلك المجموعة. إذا كان من المهم بالنسبة إليك التأكّد من أنّه يمكن للمستخدمين confirm the revocation في الإعدادات، احرص على إبطال كل إذن في مجموعة الأذونات. لمعرفة الأذونات التي تنتمي إلى مجموعة معيّنة، يمكنك استخدام PackageManager.getGroupOfPlatformPermission وPackageManager.getPlatformPermissionsForGroup.

عندما يُلغي النظام الأذونات المطلوبة، يُلغي أيضًا أذونات التشغيل في الخلفية المقابلة لها في حال عدم منح أي من أذونات التشغيل في المقدّمة المقابلة لها.

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

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