با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
مجوزها فقط برای درخواست عملکرد سیستم نیستند. همچنین می توانید نحوه تعامل سایر برنامه ها با اجزای برنامه خود را محدود کنید.
این راهنما نحوه بررسی مجموعه مجوزهایی را که برنامه دیگری اعلام کرده است توضیح می دهد. این راهنما همچنین توضیح می دهد که چگونه می توانید فعالیت ها، خدمات، ارائه دهندگان محتوا و گیرنده های پخش را پیکربندی کنید تا نحوه تعامل سایر برنامه ها با برنامه شما را محدود کنید.
مجوزهای یک برنامه دیگر را بررسی کنید
برای مشاهده مجموعه مجوزهایی که برنامه دیگری اعلام می کند، از یک دستگاه یا شبیه ساز برای تکمیل مراحل زیر استفاده کنید:
صفحه اطلاعات برنامه یک برنامه را باز کنید.
مجوزها را انتخاب کنید. صفحه مجوزهای برنامه بارگیری می شود.
این صفحه مجموعه ای از گروه های مجوز را نشان می دهد. سیستم مجموعه مجوزهایی را که یک برنامه در این گروه ها اعلام کرده است سازماندهی می کند.
تعدادی راه مفید دیگر برای بررسی مجوزها وجود دارد:
در طول تماس با یک سرویس، یک رشته مجوز را به Context.checkCallingPermission() ارسال کنید. این روش یک عدد صحیح را برمی گرداند که نشان می دهد آیا آن مجوز به فرآیند فراخوانی فعلی داده شده است یا خیر. توجه داشته باشید که این تنها زمانی قابل استفاده است که شما در حال اجرای تماسی هستید که از فرآیند دیگری دریافت می‌شود، معمولاً از طریق رابط IDL که از یک سرویس منتشر شده است یا به روش دیگری که به فرآیند دیگری داده شده است.
برای بررسی اینکه آیا به فرآیند دیگری مجوز خاصی داده شده است یا خیر، فرآیند (PID) را به Context.checkPermission() منتقل کنید.
از ویژگی android:permission برای تگ <service> در مانیفست استفاده کنید تا برنامه های دیگر را محدود کنید که می توانند شروع کنند یا به Service مرتبط متصل شوند. مجوز در طول Context.startService()Context.stopService() و Context.bindService() بررسی می شود. اگر تماس گیرنده مجوز لازم را نداشته باشد، یک SecurityException رخ می دهد.
تعامل با ارائه دهندگان محتوای برنامه خود را محدود کنید
از ویژگی 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 داده ای که در intent گنجانده شده است می دهد. برنامه‌های دیگر این مجوزها را برای URI خاص به دست می‌آورند، صرفنظر از اینکه مجوز دسترسی به داده‌های ارائه‌دهنده محتوا را دارند یا نه.
به عنوان مثال، فرض کنید یک کاربر از برنامه شما برای مشاهده یک ایمیل با پیوست تصویر استفاده می کند. سایر برنامه ها نباید به طور کلی به محتوای ایمیل دسترسی داشته باشند، اما ممکن است علاقه مند به مشاهده تصویر باشند. برنامه شما می تواند از یک intent و پرچم Intent.FLAG_GRANT_READ_URI_PERMISSION استفاده کند تا به یک برنامه مشاهده تصویر اجازه دهد تصویر را ببیند.
یکی دیگر از موارد قابل مشاهده بودن برنامه است. اگر برنامه شما Android 11 (سطح API 30) یا بالاتر را هدف قرار می دهد، سیستم برخی از برنامه ها را به طور خودکار برای برنامه شما قابل مشاهده می کند و سایر برنامه ها را به طور پیش فرض پنهان می کند. اگر برنامه شما یک ارائه دهنده محتوا داشته باشد و مجوزهای URI را به برنامه دیگری اعطا کرده باشد، برنامه شما به طور خودکار برای آن برنامه دیگر قابل مشاهده است.
از ویژگی android:permission برای تگ <receiver> استفاده کنید تا برنامه های دیگر را محدود کنید که بتوانند به BroadcastReceiver مرتبط ارسال کنند. مجوز پس از بازگشت Context.sendBroadcast() بررسی می شود، زیرا سیستم سعی می کند پخش ارسالی را به گیرنده داده شده تحویل دهد. این بدان معناست که شکست مجوز منجر به بازگرداندن یک استثنا به تماس‌گیرنده نمی‌شود - فقط Intent را ارائه نمی‌کند.
به همین ترتیب، می‌توانید مجوزی به Context.registerReceiver() بدهید تا کنترل کند کدام برنامه‌های دیگر می‌توانند به یک گیرنده ثبت‌شده برنامه‌ای پخش شوند. از طرف دیگر، می‌توانید هنگام فراخوانی Context.sendBroadcast() یک مجوز برای محدود کردن گیرنده‌های پخشی که می‌توانند پخش را دریافت کنند، ارائه کنید.
توجه داشته باشید که هم گیرنده و هم پخش کننده می توانند به مجوز نیاز داشته باشند. وقتی این اتفاق می‌افتد، هر دو بررسی مجوز باید برای ارسال هدف به هدف مرتبط انجام شود. برای اطلاعات بیشتر، محدود کردن پخش با مجوزها را ببینید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبت‌شده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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)."]]
