권한은 시스템 기능을 요청하기 위해서만 사용되는 것은 아닙니다. 다른 앱이 내 앱의 구성요소와 상호작용하는 방법을 제한할 수도 있습니다.
이 가이드에서는 다른 앱에서 선언한 권한 집합을 확인하는 방법을 설명합니다. 또한 이 가이드에서는 활동, 서비스, 콘텐츠 제공업체, broadcast receiver를 구성하여 다른 앱이 내 앱과 상호작용하는 방식을 제한하는 방법을 설명합니다.
다른 앱의 권한 확인
다른 앱에서 선언한 권한 집합을 보려면 기기 또는 에뮬레이터를 사용하여 다음 단계를 완료하세요.
앱의 앱 정보 화면을 엽니다.
권한을 선택합니다. 앱 권한 화면이 표시됩니다.
이 화면에는 권한 그룹 집합이 표시됩니다. 시스템에서는 앱이 이러한 그룹에 선언한 권한 집합을 구성합니다.
권한을 확인하는 데 유용한 여러 가지 다른 방법이 있습니다.
서비스 호출 중에 권한 문자열을 Context.checkCallingPermission()에 전달합니다.
이 메서드는 권한이 현재 호출 프로세스에 부여되었는지를 나타내는 정수를 반환합니다. 이 방법은 일반적으로 서비스에서 게시된 IDL 인터페이스를 통해서나 다른 프로세스에 지정된 다른 방법을 통해 다른 프로세스에서 들어오는 호출을 실행하는 경우에만 사용할 수 있습니다.
android:permission 속성을 매니페스트의 <provider> 태그에 사용하면 ContentProvider의 데이터에 액세스할 수 있는 앱을 제한할 수 있습니다.
(콘텐츠 제공업체가 사용할 수 있는 URI 권한이라고 하는 중요한 추가 보안 기능이 있습니다. 이에 관해서는 다음 섹션에서 설명합니다.)
다른 구성요소와 달리 두 가지 개별적인 권한 속성을 설정할 수 있습니다. android:readPermission은 제공업체의 데이터를 읽을 수 있도록 할 앱을 제한하고 android:writePermission은 데이터를 쓸 수 있도록 할 앱을 제한합니다. 참고로 제공업체가 읽기 및 쓰기 권한을 모두 사용하여 보호되는 경우 쓰기 권한만 보유하면 앱이 제공업체로부터 데이터를 읽을 수 없습니다.
시스템을 통해 개발자는 다른 앱이 앱의 콘텐츠 제공업체에 액세스할 수 있는 방법을 세밀하게 추가로 제어할 수 있습니다. 특히 콘텐츠 제공업체는 읽기 및 쓰기 권한을 사용해 자체적으로 보호하면서 제공업체의 다이렉트 고객이 특정 URI를 다른 앱과 공유하도록 계속 허용할 수 있습니다. 이 모델에 관한 앱의 지원을 선언하려면 android:grantUriPermissions 속성이나 <grant-uri-permission> 요소를 사용하세요.
예를 들어 사용자가 앱을 사용하여 이미지 첨부파일이 있는 이메일을 확인한다고 가정해 보겠습니다. 일반적으로 다른 앱은 이메일 콘텐츠에 액세스할 수 없어야 하지만, 이 이미지는 보고 싶어할 수 있습니다.
앱은 이미지 보기 앱이 이미지를 보도록 인텐트와 Intent.FLAG_GRANT_READ_URI_PERMISSION 인텐트 플래그를 사용할 수 있습니다.
또 다른 고려사항은 앱 가시성입니다. 앱이 Android 11(API 수준 30) 이상을 타겟팅한다면 시스템에서 일부 앱은 내 앱에 자동으로 표시되게 하지만 어떤 앱은 기본적으로 숨깁니다. 앱이 콘텐츠 제공업체를 보유하고 있고 다른 앱에 URI 권한을 부여한 경우 앱은 다른 앱에 자동으로 표시됩니다.
android:permission 속성을 <receiver> 태그에 사용하면 연결된 BroadcastReceiver에 브로드캐스트를 전송할 수 있는 앱을 제한할 수 있습니다.
시스템이 제출된 브로드캐스트를 지정된 수신기에 전달하려고 하므로 이 권한은 Context.sendBroadcast()가 반환된 후에 확인됩니다. 즉, 권한 오류로 인해 호출자에 예외가 다시 발생하지 않습니다. Intent만 전달되지 않습니다.
같은 방법으로, Context.registerReceiver()에 권한을 제공하여 프로그래매틱 방식으로 등록된 수신기에 브로드캐스트할 수 있는 다른 앱을 제어할 수도 있습니다. 다른 방법으로는 Context.sendBroadcast()를 호출할 때 권한을 제공하여 브로드캐스트를 수신할 수 있는 broadcast receiver를 제한할 수 있습니다.
수신기와 브로드캐스터 모두에 권한이 필요할 수 있습니다. 이 경우 두 권한 검사를 모두 통과해야만 인텐트를 연결된 타겟에 제공할 수 있습니다. 자세한 내용은 권한으로 브로드캐스트 제한을 참고하세요.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[null,null,["최종 업데이트: 2025-07-27(UTC)"],[],[],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)."]]
