تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
لا تُستخدم الأذونات لطلب وظائف النظام فقط. كما يمكنك تقييد كيفية تفاعل التطبيقات الأخرى مع مكونات تطبيقك.
يشرح هذا الدليل كيفية التحقق من مجموعة الأذونات التي أعلن عنها تطبيق آخر. يشرح الدليل أيضًا طريقة ضبط الأنشطة والخدمات
وموفِّري المحتوى وأجهزة استقبال البث لفرض قيود على كيفية تفاعل التطبيقات الأخرى مع
تطبيقك.
التأكّد من أذونات تطبيق آخر
للاطّلاع على مجموعة الأذونات التي يعلنها تطبيق آخر، استخدِم جهازًا أو محاكيًا لإكمال الخطوات التالية:
افتح شاشة معلومات التطبيق لتطبيق معيَّن.
انقر على الأذونات. يتم تحميل شاشة أذونات التطبيق.
تعرض هذه الشاشة مجموعة من مجموعات الأذونات. ينظم النظام مجموعة الأذونات
التي أعلنها التطبيق في هذه المجموعات.
وهناك بعض الطرق المفيدة الأخرى للتحقّق من الأذونات:
أثناء مكالمة إلى خدمة، أدخِل سلسلة أذونات إلى
Context.checkCallingPermission().
تعرض هذه الطريقة عددًا صحيحًا يشير إلى ما إذا كان قد تم منح هذا الإذن
لعملية الاستدعاء الحالية أم لا. لا يمكن استخدام هذا إلا عند تنفيذ مكالمة واردة من عملية أخرى، وعادةً ما يتم ذلك من خلال واجهة IDL منشورة من خدمة أو بطريقة أخرى ممنوحة لعملية أخرى.
للتحقق مما إذا تم منح عملية أخرى إذنًا معيّنًا،
عليك تمرير العملية (PID) إلى
Context.checkPermission().
استخدِم السمة android:permission للعلامة <provider> لتقييد التطبيقات الأخرى التي يمكنها الوصول إلى البيانات في ContentProvider.
(لدى موفّري المحتوى ميزة أمان إضافية مهمة متاحة لهم باسم
أذونات معرّف الموارد المنتظم (URI)، والموضّحة في
القسم التالي).
وعلى عكس المكونات الأخرى، تتوفر سمتان منفصلتان للأذونات
يمكنك ضبطهما لموفّري المحتوى: android:readPermission
تفرض قيودًا على التطبيقات الأخرى التي يمكنها القراءة من مقدّم الخدمة، و
android:writePermission تفرض قيودًا على التطبيقات الأخرى التي يمكنها الكتابة إلى موفّري المحتوى. يُرجى العِلم بأنّه إذا كان موفّر الخدمة محميًا بإذن بالقراءة والكتابة معًا،
لا يسمح الحصول على إذن الكتابة فقط للتطبيق بالقراءة من الموفّر.
يتم التحقق من الأذونات عند استرداد موفِّر الخدمة لأول مرة وعندما
ينفِّذ تطبيق عمليات على موفِّر الخدمة. وفي حال لم يكن لدى التطبيق الذي قدّم الطلب
أي من الإذنَين، يتم عرض SecurityException. إنّ استخدام
ContentResolver.query() يتطلّب
الحصول على إذن بالقراءة، في حين أنّ استخدام
ContentResolver.insert()
أو
ContentResolver.update() أو
ContentResolver.delete()
يتطلّب الحصول على إذن بالكتابة. في جميع هذه الحالات، يؤدي عدم الحصول
على الإذن المطلوب إلى ظهور SecurityException.
منح حق الوصول على أساس كل معرّف موارد منتظم (URI)
يزودك النظام بتحكم إضافي أكثر دقة في كيفية وصول التطبيقات الأخرى إلى موفري محتوى التطبيق. وعلى وجه الخصوص، يمكن لموفّر المحتوى حماية نفسه باستخدام أذونات القراءة والكتابة مع السماح للعملاء المباشرين في الوقت نفسه بمشاركة عناوين URI محدَّدة مع تطبيقات أخرى. لتأكيد أنّ تطبيقك يدعم هذا النموذج، استخدِم السمة android:grantUriPermissions أو العنصر <grant-uri-permission>.
يمكنك أيضًا منح أذونات على أساس كل معرّف موارد منتظم (URI). عند بدء
نشاط أو عرض نتيجة إلى أحد الأنشطة، اضبط علامة
القصد في Intent.FLAG_GRANT_READ_URI_PERMISSION
أو علامة النية في
Intent.FLAG_GRANT_WRITE_URI_PERMISSION
أو كلتا العلامتين. يمنح ذلك التطبيقات الأخرى أذونات للقراءة أو الكتابة أو
القراءة/الكتابة، على التوالي، لمعرّف الموارد المنتظم (URI) للبيانات المُضمَّن في
القصد. تحصل التطبيقات الأخرى على هذه الأذونات لعنوان URI محدّد بغض النظر عمّا إذا كان لديها إذن بالوصول إلى البيانات في موفِّر المحتوى بشكل عام.
على سبيل المثال، لنفترض أن أحد المستخدمين يستخدم تطبيقك لعرض رسالة إلكترونية تحتوي على مرفق صورة. وينبغي ألا تتمكن التطبيقات الأخرى من الوصول إلى محتوى البريد الإلكتروني بشكل عام، إلا أنها قد تهتم بعرض الصورة.
يمكن أن يستخدم تطبيقك حالة Intent وعلامة
النية Intent.FLAG_GRANT_READ_URI_PERMISSION للسماح لتطبيق عرض الصور برؤية الصورة.
هناك اعتبار آخر هو مستوى ظهور التطبيقات. إذا كان تطبيقك يستهدف Android 11 (مستوى واجهة برمجة التطبيقات 30) أو إصدارًا أحدث، يجعل النظام بعض التطبيقات مرئية لتطبيقك تلقائيًا ويخفي التطبيقات الأخرى تلقائيًا. إذا كان تطبيقك مزوّدًا بمزوّد محتوى
وقد منح أذونات معرّف الموارد المنتظم (URI) لتطبيق آخر، سيكون تطبيقك
مرئيًا تلقائيًا
لهذا التطبيق الآخر.
يمكنك استخدام السمة android:permission
للعلامة <receiver> لتقييد التطبيقات الأخرى التي يمكنها إرسال
أحداث البث إلى BroadcastReceiver المرتبطة.
يتم
التحقّق من الإذن بعد إرجاع Context.sendBroadcast()، حيث يحاول النظام إرسال
البث الذي تم إرساله إلى المستلِم المحدّد. ويعني هذا أنّ تعذُّر الحصول على الإذن لا يؤدي إلى إرجاع استثناء إلى
المتصل، بل أنّه لا يرسل Intent.
وبالطريقة نفسها، يمكنك توفير إذن إلى
Context.registerReceiver()
للتحكّم في التطبيقات الأخرى التي يمكن بثها إلى
جهاز استقبال مسجَّل آليًا. في المقابل، يمكنك توفير
إذن عند الاتصال بـ
Context.sendBroadcast()
لفرض قيود على أجهزة استقبال البث التي يمكنها تلقّي البث.
ملاحظة: يمكن أن يتطلب كل من جهاز الاستقبال والقائم بالبث إذنًا. وفي هذه الحالة، يجب أن يجتاز عملا التحقّق من الأذونات للوصول إلى الهدف المرتبط. لمزيد من المعلومات، يُرجى الاطّلاع على حظر عمليات البث باستخدام الأذونات.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-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-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Restrict interactions with other apps\n\nPermissions aren't only for requesting system functionality. You can also\nrestrict how other apps can interact with your app's components.\n\n\nThis guide explains how to check the set of permissions that another app has\ndeclared. The guide also explains how you can configure activities, services,\ncontent providers, and broadcast receivers to restrict how other apps can\ninteract with your app.\n| **Note:** When restricting interactions to only apps provided by one developer, such as to secure interprocess communications, we recommend using custom signature permissions. For more info, see [Define a custom app permission](/guide/topics/permissions/defining).\n\nCheck another app's permissions\n-------------------------------\n\nTo view the set of permissions that another app declares, use a device or\nemulator to complete the following steps:\n\n1. Open an app's **App info** screen.\n2. Select **Permissions** . The **App permissions** screen loads.\n\n This screen shows a set of permission groups. The system organizes the set\n of permissions that an app has declared into these groups.\n\nThere are a number of other useful ways to check permissions:\n\n- During a call into a service, pass a permission string into [`Context.checkCallingPermission()`](/reference/android/content/Context#checkCallingPermission(java.lang.String)). This method returns an integer that indicates whether that permission has been granted to the current calling process. Note that this can only be used when you are executing a call coming in from another process, usually through an IDL interface published from a service or in some other way given to another process.\n- To check whether another process has been granted a particular permission, pass the process (PID) into [`Context.checkPermission()`](/reference/android/content/Context#checkPermission(java.lang.String,%20int,%20int)).\n- To check whether another package has been granted a particular permission, pass the package name into [`PackageManager.checkPermission()`](/reference/android/content/pm/PackageManager#checkPermission(java.lang.String,%20java.lang.String)).\n\nRestrict interactions with your app's activities\n------------------------------------------------\n\n\nUse the `android:permission` attribute to\nthe [`\u003cactivity\u003e`](/guide/topics/manifest/activity-element) tag in the manifest to restrict which other\napps can start that\n[Activity](/reference/android/app/Activity). The\npermission is checked during\n[Context.startActivity()](/reference/android/content/Context#startActivity(android.content.Intent)) and\n[Activity.startActivityForResult()](/reference/android/app/Activity#startActivityForResult(android.content.Intent, int)).\nIf the caller doesn't have the required permission, then a\n[SecurityException](/reference/java/lang/SecurityException)\noccurs.\n\nRestrict interactions with your app's services\n----------------------------------------------\n\n\nUse the `android:permission` attribute to\nthe [`\u003cservice\u003e`](/guide/topics/manifest/service-element) tag in the manifest to restrict which other\napps can start or bind to the associated\n[Service](/reference/android/app/Service).\nThe permission is checked during\n[Context.startService()](/reference/android/content/Context#startService(android.content.Intent)),\n[Context.stopService()](/reference/android/content/Context#stopService(android.content.Intent)), and\n[Context.bindService()](/reference/android/content/Context#bindService(android.content.Intent, android.content.ServiceConnection, int)).\nIf the caller doesn't have the required permission, then a `SecurityException`\noccurs.\n\nRestrict interactions with your app's content providers\n-------------------------------------------------------\n\n\nUse the `android:permission` attribute to\nthe [`\u003cprovider\u003e`](/guide/topics/manifest/provider-element) tag to restrict which other apps can access\nthe data in a\n[ContentProvider](/reference/android/content/ContentProvider).\n(Content providers have an important\nadditional security facility available to them called\n[URI permissions](#uri), which is described in the following\nsection.)\nUnlike for the other components, there are two separate permission attributes\nyou can set for content providers: [`android:readPermission`](/guide/topics/manifest/provider-element#rprmsn)\nrestricts which other apps can read from the provider, and\n[`android:writePermission`](/guide/topics/manifest/provider-element#wprmsn) restricts\nwhich other apps can write to it. Note that if a provider is protected with\nboth a read and write permission, holding only the write permission doesn't\npermit an app to read from a provider.\n\n\nThe permissions are checked when the provider is first retrieved and when\nan app performs operations on the provider. If the requesting app doesn't\nhave either permission, a `SecurityException` occurs. Using\n[ContentResolver.query()](/reference/android/content/ContentResolver#query(android.net.Uri, java.lang.String[], android.os.Bundle, android.os.CancellationSignal)) requires\nthe read permission; using\n[ContentResolver.insert()](/reference/android/content/ContentResolver#insert(android.net.Uri, android.content.ContentValues)),\n[ContentResolver.update()](/reference/android/content/ContentResolver#update(android.net.Uri, android.content.ContentValues, java.lang.String, java.lang.String[])), or\n[ContentResolver.delete()](/reference/android/content/ContentResolver#delete(android.net.Uri, java.lang.String, java.lang.String[]))\nrequires the write permission. In all of these cases, not holding the\nrequired permission results in a `SecurityException`.\n\n### Give access on a per-URI basis\n\nThe system provides you with additional fine-grained control over how other apps\ncan access your app's content providers. In particular, your content provider\ncan protect itself with read and write permissions while still allowing its\ndirect clients to share specific URIs with other apps. To declare\nyour app's support for this model, use the\n[`android:grantUriPermissions`](/guide/topics/manifest/provider-element#gprmsn)\nattribute or the\n[`\u003cgrant-uri-permission\u003e`](/guide/topics/manifest/grant-uri-permission-element)\nelement.\n\nYou can also grant permissions on a per-URI basis. When starting an\nactivity or returning a result to an activity, set the\n[`Intent.FLAG_GRANT_READ_URI_PERMISSION`](/reference/android/content/Intent#FLAG_GRANT_READ_URI_PERMISSION)\nintent flag, the\n[`Intent.FLAG_GRANT_WRITE_URI_PERMISSION`](/reference/android/content/Intent#FLAG_GRANT_WRITE_URI_PERMISSION)\nintent flag, or both flags. This gives other apps read, write, or\nread/write permissions, respectively, for the data URI that's included in the\nintent. Other apps gain these permissions for the specific URI regardless of\nwhether they have permission to access data in the content provider more\ngenerally.\n\nFor example, suppose that a user is using your app to view an email with an\nimage attachment. Other apps shouldn't be able to access the\nemail contents in general, but they might be interested in viewing the image.\nYour app can use an intent and the `Intent.FLAG_GRANT_READ_URI_PERMISSION`\nintent flag to let an image-viewing app see the image.\n\nAnother consideration is [app visibility](/training/package-visibility). If your app targets Android 11 (API\nlevel 30) or higher, the system makes some apps visible to your app\nautomatically and hides other apps by default. If your app has a content\nprovider and has granted URI permissions to another app, your app is\n[automatically visible](/training/package-visibility/automatic)\nto that other app.\n\nFor more information, view the reference material for the\n[`grantUriPermission()`](/reference/android/content/Context#grantUriPermission(java.lang.String,%20android.net.Uri,%20int)),\n[`revokeUriPermission()`](/reference/android/content/Context#revokeUriPermission(android.net.Uri,%20int)),\nand\n[`checkUriPermission()`](/reference/android/content/Context#checkUriPermission(android.net.Uri,%20int,%20int,%20int))\nmethods.\n\nRestrict interactions with your app's broadcast receivers\n---------------------------------------------------------\n\n\nUse the `android:permission` attribute to\nthe [`\u003creceiver\u003e`](/guide/topics/manifest/receiver-element) tag to restrict which other apps can send\nbroadcasts to the associated\n[BroadcastReceiver](/reference/android/content/BroadcastReceiver).\nThe permission is\nchecked *after* [Context.sendBroadcast()](/reference/android/content/Context#sendBroadcast(android.content.Intent)) returns, as the system tries to deliver the\nsubmitted broadcast to the given receiver. This means that a permission\nfailure doesn't result in an exception being thrown back to the\ncaller---it just doesn't deliver the\n[Intent](/reference/android/content/Intent).\n\n\nIn the same way, you can supply a permission to\n[Context.registerReceiver()](/reference/android/content/Context#registerReceiver(android.content.BroadcastReceiver, android.content.IntentFilter, java.lang.String, android.os.Handler))\nto control which other apps can broadcast to a\nprogrammatically registered receiver. Going the other way, you can supply a\npermission when calling\n[Context.sendBroadcast()](/reference/android/content/Context#sendBroadcast(android.content.Intent, java.lang.String))\nto restrict which broadcast receivers can receive the broadcast.\n\n\nNote that both a receiver and a broadcaster can require a permission. When\nthis happens, both permission checks must pass for the intent to be delivered\nto the associated target. For more information, see\n[Restricting broadcasts with permissions](/guide/components/broadcasts#restrict-broadcasts-permissions)."]]
