في 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 Compatibility Test Suite (CTS).
- يجب أن تطالب التطبيقات المستخدمين بمنح أذونات التطبيق في وقت التشغيل. للحصول على التفاصيل ، راجع تحديث التطبيقات . يجوز منح استثناءات محدودة للتطبيقات والمعالجات الافتراضية التي توفر وظائف الجهاز الأساسية الأساسية للتشغيل المتوقع للجهاز. (على سبيل المثال ، قد يكون لتطبيق Dialer الافتراضي للجهاز للتعامل مع
ACTION_CALLوصول إلى إذن الهاتف.) للحصول على التفاصيل ، راجع إنشاء استثناءات . - يجب أن تستهدف التطبيقات التي تم تحميلها مسبقًا والتي تحتوي على أذونات خطيرة مستوى واجهة برمجة التطبيقات 23 وتحافظ على نموذج إذن وقت التشغيل. أي أن تدفق واجهة المستخدم أثناء تثبيت التطبيق يجب ألا ينحرف عن تنفيذ AOSP لـ PermissionController ، يمكن للمستخدمين إبطال الأذونات الخطيرة للتطبيقات المثبتة مسبقًا ، وما إلى ذلك.
- يجب أن تستخدم التطبيقات بدون رأس نشاطًا لطلب أذونات أو لمشاركة UID مع تطبيق آخر لديه الأذونات اللازمة. للحصول على التفاصيل ، انظر التطبيقات مقطوعة الرأس .
ترحيل الأذونات
تظل الأذونات الممنوحة للتطبيقات على Android 5.x ممنوحة بعد التحديث إلى Android 6.0 أو أعلى ، ولكن يمكن للمستخدمين إلغاء هذه الأذونات في أي وقت.
في تحديث Android 9 إلى 10 ، يتم السماح بجميع الأذونات المقيدة بشدة. للحصول على تفاصيل حول تنفيذ أذونات تقسيم المقدمة / الخلفية ، راجع تغيير خصوصية Android 10 ، بدءًا من طلب موقع الخلفية .
اندماج
عند دمج نموذج أذونات وقت تشغيل التطبيق لنظام Android 6.0 والإصدارات الأحدث ، يجب عليك تحديث التطبيقات المثبتة مسبقًا للعمل مع النموذج الجديد. يمكنك أيضًا تحديد استثناءات للتطبيقات التي تعتبر المعالجات / الموفرين الافتراضيين للوظائف الأساسية ، وتحديد الأذونات المخصصة ، وتخصيص السمة المستخدمة في تطبيق PermissionController .
تحديث التطبيقات
التطبيقات الموجودة على صورة النظام والتطبيقات المثبتة مسبقًا ليست أذونات مضمونة مسبقًا تلقائيًا. نحن نشجعك على العمل مع مطوري التطبيقات المثبتة مسبقًا (المصنّع الأصلي للجهاز ، والناقل ، والجهات الخارجية) لإجراء تعديلات التطبيق المطلوبة باستخدام إرشادات المطورين . على وجه التحديد ، يجب عليك التأكد من تعديل التطبيقات المثبتة مسبقًا لتجنب الأعطال والمشكلات الأخرى عند إبطال المستخدمين للأذونات.
التطبيقات المحملة مسبقًا
في Android 9 والإصدارات الأقدم ، يجب أن تستهدف التطبيقات المحملة مسبقًا التي تستخدم أذونات خطيرة مستوى واجهة برمجة التطبيقات 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 / Carrier إلى مجموعات الأذونات الحالية ، تمامًا كما تفعل في Android 5.x والإصدارات السابقة.
في Android 6.0 والإصدارات الأحدث ، إذا أضفت إذنًا خطيرًا جديدًا ، فيجب التعامل معه بنفس طريقة التعامل مع الأذونات الخطيرة الأخرى (مطلوبة أثناء وقت تشغيل التطبيق وقابلة للإلغاء من قبل المستخدمين). خاصة:
- يمكنك إضافة أذونات جديدة إلى مجموعة حالية ، لكن لا يمكنك تعديل تعيين AOSP للأذونات الخطرة ومجموعات الأذونات الخطيرة. (بمعنى آخر ، لا يمكنك إزالة إذن من مجموعة وتخصيصه لمجموعة أخرى).
- يمكنك إضافة مجموعات أذونات جديدة في التطبيقات المثبتة على الجهاز ، ولكن لا يمكنك إضافة مجموعات أذونات جديدة في بيان النظام الأساسي.
أذونات الاختبار
يشتمل Android على اختبارات Compatibility Test Suite (CTS) التي تتحقق من تعيين الأذونات الفردية للمجموعات الصحيحة. يعد اجتياز هذه الاختبارات شرطًا لتوافق Android 6.0 والإصدارات الأحدث من CTS.
إبطال الأذونات
في Android 13 والإصدارات الأحدث ، يمكنك إلغاء أذونات وقت التشغيل الممنوحة لك باستخدام Context.revokeSelfPermissionsOnKill() . يحدث الإلغاء بشكل غير متزامن ويتم تشغيله عندما يكون القيام بذلك آمنًا دون إزعاج المستخدم. عندما يتم تشغيل الإبطال ، سيتم إنهاء جميع العمليات التي تعمل في UID المتصل.
من المهم أن نفهم أن إلغاء إذن واحد قد لا ينعكس في إعدادات واجهة المستخدم ، التي تتعامل مع الأذونات حسب المجموعة. عادةً ، سيتم عرض مجموعة الأذونات على أنها ممنوحة طالما تم منح إذن واحد على الأقل في تلك المجموعة. إذا كان ضمان قدرة المستخدمين على تأكيد الإلغاء في الإعدادات أمرًا مهمًا بالنسبة لك ، فتأكد من إلغاء كل إذن في مجموعة الأذونات. لمعرفة الأذونات التي تنتمي إلى مجموعة معينة ، يمكنك استخدام PackageManager.getGroupOfPlatformPermission و PackageManager.getPlatformPermissionsForGroup .
عندما يبطل النظام الأذونات المطلوبة ، فإنه يلغي أيضًا أذونات الخلفية المقابلة إذا لم يتم منح أي من أذونات المقدمة المقابلة.
لن يتم تشغيل الإلغاء طالما بقيت العملية في المقدمة ولكن يمكن أيضًا تشغيلها على الفور عن طريق قتل جميع العمليات التي تعمل في المعرّف الحالي يدويًا ، على سبيل المثال باستخدام System.exit() . ومع ذلك ، فمن المستحسن السماح للنظام بتحديد وقت تشغيله.
بعد أن يصبح إلغاء الإذن ساريًا ، يمكنك طلبه مرة أخرى ، وسيُطلب من المستخدم منح أو رفض الطلب. لا يمكن طلب إذن تم رفضه مسبقًا من قبل المستخدم. بينما يتم تشجيعك على إلغاء الأذونات التي تمتلكها حاليًا ولكن لم تعد هناك حاجة إليها ، يجب أن تكون حريصًا على عدم إبلاغ المستخدم بالإلغاء إلا بعد أن يصبح ساريًا.