تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يوفّر الإذن الخاص الحماية للوصول إلى موارد النظام التي تتسم بحساسية خاصة أو لا ترتبط بشكل مباشر بخصوصية المستخدم. تختلف هذه الأذونات عن أذونات وقت التثبيت وأذونات وقت التشغيل.
الشكل 1. شاشة أذونات خاصة للتطبيقات في إعدادات النظام
تشمل بعض الأمثلة على الأذونات الخاصة ما يلي:
جدولة المنبّهات المحدَّدة الوقت
عرض المحتوى والرسم فوق التطبيقات الأخرى
الوصول إلى جميع بيانات مساحة التخزين
تظهر التطبيقات التي تحدّد إذنًا خاصًا في صفحة أذونات خاصة للتطبيقات
في إعدادات النظام (الشكل 1). لمنح التطبيق إذنًا خاصًا، على المستخدم الانتقال إلى هذه الصفحة: الإعدادات > التطبيقات > أذونات خاصة للتطبيقات.
صمِّم تجربة المستخدم في تطبيقك بحيث تكون الإجراءات المحدّدة في تطبيقك مرتبطة بأذونات خاصة محدّدة. أوضِح للمستخدمين الإجراءات التي قد تتطلّب منهم منح تطبيقك الإذن بالوصول إلى بيانات المستخدمين الخاصة.
انتظِر حتى يطلب المستخدم تنفيذ مهمة أو إجراء في تطبيقك يتطلّب الوصول إلى بيانات خاصة محدّدة. في ذلك الوقت، يمكن لتطبيقك طلب الإذن الخاص اللازم للوصول إلى تلك البيانات.
تحقَّق مما إذا كان المستخدم قد منح الإذن الخاص الذي يتطلبه تطبيقك. لإجراء ذلك، استخدِم وظيفة التحقّق المخصّصة لكل إذن. وفي حال منح الإذن، يمكن لتطبيقك الوصول إلى بيانات المستخدم الخاصة. وإذا استمرت المشكلة، فانتقِل إلى الخطوة التالية. ملاحظة: يجب التحقّق مما إذا كان لديك الإذن في كل مرة تنفّذ فيها عملية تتطلّب هذا الإذن.
قدِّم للمستخدم سببًا في عنصر واجهة مستخدم يوضّح بوضوح البيانات التي يحاول تطبيقك الوصول إليها والمزايا التي يمكن أن يقدّمها التطبيق للمستخدم إذا منح الإذن الخاص. بالإضافة إلى ذلك، بما أنّ تطبيقك يوجّه المستخدمين إلى إعدادات النظام لمنح الإذن، يجب أيضًا تضمين تعليمات موجزة توضّح كيفية منح المستخدمين الإذن هناك. يجب أن توفّر واجهة مستخدم السبب خيارًا واضحًا للمستخدم لإيقاف منح الإذن. بعد أن يقرّ المستخدم
بالسبب، انتقِل إلى الخطوة التالية.
اطلب الإذن الخاص الذي يحتاج إليه تطبيقك للوصول إلى بيانات المستخدم الخاصة. من المحتمل أن يتضمّن ذلك نية الانتقال إلى الصفحة ذات الصلة في إعدادات النظام حيث يمكن للمستخدم منح الإذن. وعلى عكس
أذونات وقت التشغيل، لا يتوفّر
مربّع حوار منبثق خاص بالأذونات.
تحقَّق من ردّ المستخدم، أي ما إذا اختار منح الإذن الخاص أو رفضه، في طريقة onResume().
إذا منح المستخدم الإذن لتطبيقك، يمكنك الوصول إلى بيانات المستخدم الخاصة. إذا رفض المستخدم الإذن بدلاً من ذلك، عليك خفض إصدار تطبيقك على نحو ملائم لكي يوفّر للمستخدم وظائف بدون المعلومات المحمية بموجب هذا الإذن.
الشكل 2. سير العمل الخاص بتعريف الأذونات الخاصة وطلبها على Android
طلب أذونات خاصة
وعلى عكس أذونات وقت التشغيل، يجب أن يمنح المستخدم أذونات خاصة من صفحة أذونات خاصة للتطبيقات في إعدادات النظام. ويمكن للتطبيقات توجيه المستخدمين إلى هناك باستخدام Intent، ما يؤدي إلى إيقاف التطبيق مؤقتًا وفتح صفحة الإعدادات المقابلة لأي إذن خاص.
بعد أن يعود المستخدم إلى التطبيق، يمكن للتطبيق التحقّق مما إذا تم منح الإذن في الدالة onResume().
يوضّح نموذج الرمز البرمجي التالي كيفية طلب الإذن الخاص
SCHEDULE_EXACT_ALARMS
من المستخدمين:
valalarmManager=getSystemService<AlarmManager>()!!when{// if permission is granted, proceed with scheduling exact alarms…alarmManager.canScheduleExactAlarms()->{alarmManager.setExact(...)}else->{// ask users to grant the permission in the corresponding settings pagestartActivity(Intent(ACTION_REQUEST_SCHEDULE_EXACT_ALARM))}}
نموذج الرمز البرمجي للتحقّق من الإذن والتعامل مع قرارات المستخدم في onResume():
overridefunonResume(){// ...if(alarmManager.canScheduleExactAlarms()){// proceed with the action (setting exact alarms)alarmManager.setExact(...)}else{// permission not yet approved. Display user notice and gracefully degradeyourappexperience.alarmManager.setWindow(...)}}
أفضل الممارسات والنصائح
تقدّم الأقسام التالية بعض أفضل الممارسات والاعتبارات عند طلب أذونات خاصة.
وعلى غرار أذونات التشغيل، يجب أن تطلب التطبيقات أذونات خاصة في سياقها عندما يطلب المستخدم إجراءً معيّنًا يتطلّب الحصول على الإذن. على سبيل المثال، انتظِر إلى أن يجدول المستخدم رسالة إلكترونية ليتم إرسالها في وقت معيّن قبل طلب الإذن SCHEDULE_EXACT_ALARMS.
شرح الطلب
قدِّم سببًا قبل إعادة التوجيه إلى إعدادات النظام. بما أنّ المستخدمين يغادرون التطبيق مؤقتًا لمنح أذونات خاصة، اعرض واجهة مستخدم داخل التطبيق قبل إطلاق الغرض إلى صفحة أذونات خاصة للتطبيقات في إعدادات النظام. يجب أن توضّح واجهة المستخدم هذه بوضوح سبب احتياج التطبيق إلى الإذن وكيفية منحه من خلال صفحة الإعدادات.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-08-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-08-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["A *special permission* guards access to system resources that are particularly\nsensitive or not directly related to user privacy. These permissions are\ndifferent than [install-time\npermissions](/guide/topics/permissions/overview#install-time) and [runtime\npermissions](/guide/topics/permissions/overview#runtime). \n**Figure 1.** The **Special app access** screen in system settings.\n\nSome examples of special permissions include:\n\n- Scheduling exact alarms.\n- Displaying and drawing over other apps.\n- Accessing all storage data.\n\nApps that declare a special permission are shown in the **Special app access**\npage in system settings (figure 1). To grant a special permission to the app, a\nuser must navigate to this page: **Settings \\\u003e Apps \\\u003e Special app access**.\n| **Note:** Special permissions should be only used in specific use cases, and there may be policy implications to adding them in your app,\n\nWorkflow\n\nTo request a special permission, do the following:\n\n1. In your app's manifest file, [declare the special\n permissions](/training/permissions/declaring) that your app might need to request.\n2. Design your app's UX so that specific actions in your app are associated with specific special permissions. Let users know which actions might require them to grant permission for your app to access private user data.\n3. [Wait for the user](/training/permissions/requesting#principles) to invoke the task or action in your app that requires access to specific private user data. At that time, your app can request the special permission that's required for accessing that data.\n4. Check whether the user has already granted the special permission that your app requires. To do so, use each permission's [custom checking\n function](#check-method). If granted, your app can access the private user data. If not, continue to the next step. Note: You must check whether you have the permission every time you perform an operation that requires that permission.\n5. [Present a rationale](#explain) to the user in a UI element that clearly explains what data your app is trying to access and what benefits the app can provide to the user if they grant the special permission. In addition, since your app sends users to system settings to grant the permission, also include brief instructions that explain how users can grant the permission there. The rationale UI should provide a clear option for the user to opt-out of granting the permission. After the user acknowledges the rationale, continue to the next step.\n6. [Request the special permission](#request) that your app requires to access the private user data. This likely involves an intent to the corresponding page in system settings where the user can grant the permission. Unlike [runtime permissions](/guide/topics/permissions/overview#runtime), there is no popup permission dialog.\n7. Check the user's response -- whether they chose to grant or deny the special permission -- in the `onResume()` method.\n8. If the user granted the permission to your app, you can access the private user data. If the user denied the permission instead, [gracefully degrade\n your app experience](/training/permissions/requesting#handle-denial) so that it provides functionality to the user without the information that's protected by that permission.\n\n**Figure 2.** Workflow for declaring and requesting special permissions on Android.\n\nRequest special permissions\n\nUnlike [runtime permissions](/guide/topics/permissions/overview#runtime), the\nuser must grant special permissions from the **Special App Access** page in\nsystem settings. Apps can send users there using an intent, which pauses the app\nand launches the corresponding settings page for a given special permission.\nAfter the user returns to the app, the app can check if the permission has been\ngranted in the `onResume()` function.\n\nThe following sample code shows how to request the\n[`SCHEDULE_EXACT_ALARMS`](/reference/android/Manifest.permission#SCHEDULE_EXACT_ALARM)\nspecial permission from users: \n\n val alarmManager = getSystemService\u003cAlarmManager\u003e()!!\n when {\n // if permission is granted, proceed with scheduling exact alarms...\n alarmManager.canScheduleExactAlarms() -\u003e {\n alarmManager.setExact(...)\n }\n else -\u003e {\n // ask users to grant the permission in the corresponding settings page\n startActivity(Intent(ACTION_REQUEST_SCHEDULE_EXACT_ALARM))\n }\n }\n\nSample code to check the permission and handle user decisions in `onResume()`: \n\n override fun onResume() {\n // ...\n\n if (alarmManager.canScheduleExactAlarms()) {\n // proceed with the action (setting exact alarms)\n alarmManager.setExact(...)\n }\n else {\n // permission not yet approved. Display user notice and gracefully degrade\n your app experience.\n alarmManager.setWindow(...)\n }\n }\n\nBest practices and tips\n\nThe following sections provide some best practices and considerations when\nrequesting special permissions.\n\nEach permission has its own check method\n\nSpecial permissions operate differently than [runtime\npermissions](/training/permissions/requesting#request-permission). Instead,\nrefer to the [permissions API reference\npage](/reference/android/Manifest.permission) and use the custom access check\nfunctions for each special permission. Examples include\n[`AlarmManager#canScheduleExactAlarms()`](/reference/android/app/AlarmManager#canScheduleExactAlarms())\nfor the\n[`SCHEDULE_EXACT_ALARMS`](/reference/android/Manifest.permission#SCHEDULE_EXACT_ALARM)\npermission and\n[`Environment#isExternalStorageManager()`](/reference/android/os/Environment#isExternalStorageManager())\nfor the\n[`MANAGE_EXTERNAL_STORAGE`](/reference/android/Manifest.permission#MANAGE_EXTERNAL_STORAGE)\npermission.\n\nRequest in-context\n\nSimilar to runtime permissions, apps should request special permissions\nin-context when the user requests a specific action that requires the\npermission. For example, wait to request the `SCHEDULE_EXACT_ALARMS` permission\nuntil the user schedules an email to be sent at a specific time.\n\nExplain the request\n\nProvide a rationale before redirecting to system settings. Since users leave the\napp temporarily to grant special permissions, show an in-app UI before you\nlaunch the intent to the **Special App Access** page in system settings. This UI\nshould clearly explain why the app needs the permission and how the user should\ngrant it on the settings page."]]