To enforce your own permissions, you must first declare them in your AndroidManifest.xml using one or more
For example, an application that wants to control who can start one of its activities could declare a permission for this operation as follows:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.me.app.myapp" >
<permission android:name="com.me.app.myapp.permission.DEADLY ACTIVITY"
For example, an application that needs to monitor incoming SMS messages would specify:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.android.app.myapp" >
<uses-permission android:name="android.permission.RECEIVE SMS" /> </manifest>
android:label="@string/permlab deadlyActivity" android:description="@string/permdesc deadlyActivity" android:permissionGroup="android.permission-group.COST MONEY" android:protectionLevel="dangerous" /> </manifest>
The <protectionLevel> attribute is required, telling the system how the user is to be informed of applications requiring the permission, or who is allowed to hold that permission, as described in the linked documentation.
The <permissionGroup> attribute is optional, and only used to help the system display permissions to the user. You will usually want to set this to either a standard system group (listed in android.Manifest.permission group) or in more rare cases to one defined by yourself. It is preferred to use an existing group, as this simplifies the permission UI shown to the user.
Note that both a label and description should be supplied for the permission. These are string resources that can be displayed to the user when they are viewing a list of permissions (android: label) or details on a single permission ( android:description). The label should be short, a few words describing the key piece of functionality the permission is protecting. The description should be a couple sentences describing what the permission allows a holder to do. Our convention for the description is two sentences, the first describing the permission, the second warning the user of what bad things can happen if an application is granted the permission.
Here is an example of a label and description for the CALL_PHONE permission:
<string name="permlab callPhone">directly call phone numbers</string> <string name="permdesc callPhone">Allows the application to call phone numbers without your intervention. Malicious applications may cause unexpected calls on your phone bill. Note that this does not allow the application to call emergency numbers.</string>
You can look at the permissions currently defined in the system with the shell command adb shell pm list permissions. In particular, the '-s' option displays the permissions in a form roughly similar to how the user will see them:
$ adb shell pm list permissions -s All Permissions:
Network communication: view Wi-Fi state, create Bluetooth connections, full Internet access, view network state
Your location: access extra location provider commands, fine (GPS) location, mock location sources for testing, coarse (network-based) location
Services that cost you money: send SMS messages, directly call phone numbers...
High-level permissions restricting access to entire components of the system or application can be applied through your AndroidManifest.xml. All that this requires is including an android:permission attribute on the desired component, naming the permission that will be used to control access to it.
Activity permissions (applied to the <activity> tag) restrict who can start the associated activity. The permission is checked during Context.startActivityf) and Activity.startActivityForResultQ: if the caller does not have the required permission then SecurityException is thrown from the call.
BroadcastReceiver permissions (applied to the <receiver> tag) restrict who can send broadcasts to the associated receiver. The permission is checked afterContext.sendBroadcastf) returns, as the system tries to deliver the submitted broadcast to the given receiver. As a result, a permission failure will not result in an exception being thrown back to the caller: it will just not deliver the intent. In the same way, a permission can be supplied to Context.registerReceiverf) to control who can broadcast to a programmatically registered receiver. Going the other way, a permission can be supplied when calling Context.sendBroadcastf) to restrict which BroadcastReceiver objects are allowed to receive the broadcast (see below).
ContentProvider permissions (applied to the <provider> tag) restrict who can access the data in a ContentProvider. (Content providers have an important additional security facility available to them called URI permissions which is described later.) Unlike the other components, there are two separate permission attributes you can set: android:readPermission restricts who can read from the provider, and android:writePermission restricts who can write to it. Note that if a provider is protected with both a read and write permission, holding only the write permission does not mean you can read from a provider. The permissions are checked when you first retrieve a provider (if you don't have either permission, a SecurityException will be thrown), and as you perform operations on the provider. Using ContentResolver.query() requires holding the read permission: using ContentResolver.insert(), ContentResolver.update(), ContentResolver.delete() requires the write permission. In all of these cases, not holding the required permission results in a SecurityException being thrown from the call.
In addition to the permission enforcing who can send Intents to a registered BroadcastReceiver (as described above), you can also specify a required permission when sending a broadcast. By calling Context.sendBroadcast() with a permission string, you require that a receiver's application must hold that permission in order to receive your broadcast.
Note that both a receiver and a broadcaster can require a permission. When this happens, both permission checks must pass for the Intent to be delivered to the associated target.
Arbitrarily fine-grained permissions can be enforced at any call into a service. This is accomplished with the Context.checkCallingPermission() method. Call with a desired permission string and it will return an integer indicating 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.
There are a number of other useful ways to check permissions. If you have the pid of another process, you can use the Context method Context.checkPermission(String, int, int) to check a permission against that pid. If you have the package name of another application, you can use the direct PackageManager method PackageManager.checkPermission(String, String) to find out whether that particular package has been granted a specific permission.
Service permissions (applied to the <service> tag) restrict who can start or bind to the associated service. The permission is checked during Context.startService(), Context.stopService() and Context.bindService(): if the caller does not have the required permission then SecurityException is thrown from the call.
Was this article helpful?