Security and Permissions in Android
Android is a multi-process system, where each application (and parts of the system) runs in its
own process. Most security between applications and the system is enforced at the process
level through standard Linux facilities, such as user and group IDs that are assigned to
applications. Additional finer-grained security features are provided through a "permission"
mechanism that enforces restrictions on the specific operations that a particular process can
- User IDs and File Access
- Using Permissions
- Declaring and Enforcing Permissions
- Enforcing Permissions in AndroidManifest.xml
- Enforcing Permissions when Broadcasting Intents
- Other Permission Enforcement
User IDs and File AccessEach Android package (.apk) file installed on the device is given its own unique Linux user ID,
creating a sandbox for it and preventing it from touching other applications (or other applications
from touching it). This user ID is assigned to it when the application is installed on the device,
and generally remains constant for the duration of its life on that device.
Because security enforcement happens at the process level, the code of any two packages can
not normally run in the same process, since they need to run as different Linux users. You can
use the sharedUserId attribute in the
AndroidManifest.xml's manifest tag of each package to have
them assigned the same user ID. By doing this, for purposes of security the two packages are
then treated as being the same application, with the same user ID and file permissions. Note that
in order to retain security, only two applications signed with the same signature (and requesting
the same sharedUserId) will be given the same user ID.
Any files created by an application will be assigned that application's user ID, and not normally
accessible to other packages. When creating a new file with getSharedPreferences(String, int),
openFileOutput(String, int), or createDatabase(String, int, int, SQLiteDatabase.CursorFactory),
you can use the MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE flags to allow
any other package to read/write the file. When setting these flags, the file is still owned by your
application, but its global read and/or write permissions have been set appropriately so any other
application can see it.
Using PermissionsA basic Android application has no permissions associated with it, meaning it can not do anything
that would adversely impact the user experience or any data on the device. To make use of
protected features of the device, you must include in your
AndroidManifest.xml one or more
<uses-permission> tags declaring the permissions that your application needs.
For example, an application that needs to monitor incoming SMS messages would specify:
<uses-permission android:name="android.permission.RECEIVE_SMS" />
At application install time, permissions requested by the application are granted to it by the package
installer, based on checks with trusted authorities and interaction with the user. No checks with the
user are done while an application is running: it either was granted a particular permission when
installed, and can use that feature as desired, or the permission was not granted and any attempt to
use the feature will fail without prompting the user.
Often times a permission failure will result in a SecurityException being thrown back to the
application. However, this is not guaranteed to occur everywhere. For example, the
broadcastIntent(Intent) method checks permissions as data is being delivered to each receiver, after
the method call has returned, so you will not receive an exception if there are permission failures.
In almost all cases, however, a permission failure will be printed to the system log.
The permissions provided by the Android system can be found at Manifest.permission. Any
application may also define and enforce its own permissions, so this is not a comprehensive list of
all possible permissions.
A particular permission may be enforced at a number of places during your program's operation:
- At the time of a call into the system, to prevent an application from executing certain functions.
- When starting an activity, to prevent applications from launching activities of other applications.
- Both sending and receiving Intent broadcasts, to control who can receive your broadcast or
who can send a broadcast to you.
- When accessing and operating on a content provider.
- Binding or starting a service.
Declaring and Enforcing PermissionsTo enforce your own permissions, you must first declare them in your
AndroidManifest.xml using one
For example, an application that wants to control who can start one of its activities could declare a
permission for this operation as follows:
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 (
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">Call Phone Numbers</string>
<string name="permdesc_callPhone">Allows application to call
phone numbers without your intervention. Bad applications may
cause unexpected calls on your phone bill.</string>
Enforcing Permissions in AndroidManifest.xmlHigh-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.startActivity() and Activity.startSubActivity(); if the caller does
not have the required permission then SecurityException is thrown from the call.
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.
IntentReceiver permissions (applied to the <receiver> tag) restrict who can broadcast Intent objects
to the associated receiver. The permission is checked after Context.broadcastIntent() returns, as the
system tries to deliver the submitted Intent 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.registerReceiver() to control who can broadcast to a
programmatically registered receiver. Going the other way, a permission can be supplied when calling
Context.broadcastIntent() to restrict which IntentReceiver objects are allowed to receive the broadcast
ContentProvider permissions (applied to the <provider> tag) restrict who can access the data in a
ContentProvider. 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(), or Cursor.commitUpdates() requires the write permission. In all of these
cases, not holding the required permission results in a SecurityException being thrown from the call.
Enforcing Permissions when Broadcasting IntentsIn addition to the permission enforcing who can send Intents to a registered IntentReceiver (as described
above), you can also specify an permission when broadcasting an Intent. By calling
Context.broadcastIntent() with a permission string, you require that a receiver's application must hold
that permission in order to receive your Intent.
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.
Other Permission EnforcementArbitrarily 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 as 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
Context.checkPermission(String, String) to find out whether that particular package has been granted a specific