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

في Android 6.0 والإصدارات الأحدث، تم تصميم نموذج أذونات تطبيقات 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

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

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

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

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

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

تحدث القائمة المسموح بها أثناء التثبيت، ومتى

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

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

متطلبات

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

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

ترحيل الأذونات

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

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

اندماج

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

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

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

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

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

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

تطبيقات بلا رأس

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

  • في نظام التشغيل Android 5.1 والإصدارات الأقدم، يمكن للتطبيقات مقطوعة الرأس أن تطلب أذونات عند تثبيتها، أو إذا تم تثبيتها مسبقًا دون استخدام أي نشاط.
  • في نظام التشغيل Android 6.0 والإصدارات الأحدث، يجب أن تستخدم التطبيقات مقطوعة الرأس إحدى الطرق التالية لطلب الأذونات:
    • أضف نشاطًا لطلب الأذونات. (هذا هو الأسلوب المفضل.)
    • قم بمشاركة UID مع تطبيق آخر لديه الأذونات اللازمة. استخدم هذه الطريقة فقط عندما تحتاج إلى النظام الأساسي للتعامل مع ملفات 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

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

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

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

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

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

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

إلغاء الأذونات

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

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

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

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

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