Skip main navigation
We use cookies to give you a better experience, if that’s ok you can close this message and carry on browsing. For more info read our cookies policy.
We use cookies to give you a better experience. Carry on browsing if you're happy with this, or read our cookies policy for more information.

Overview of Android permissions

If an Android application requires a capability that is not provided by the basic sandbox then it must request permission.

Android permissions are the mechanism by which access to resources and capabilities provided by the Android system or other apps is controlled. If an app tries to do something for which it does not have permission a SecurityException will be thrown.

Notes for Nerds: there are cases where a SecurityException will not be thrown. One example is calls to sendBroadcast(). This is because the permission check is done on a per-recipient basis as the broadcast is being delivered, and the call to sendBroadcast() will have already returned by then.

Permission protection levels

Permissions can have one of four protection levels:

  1. Normal Permissions: these present little or no risk to the user’s privacy, or will have little or no effect on other applications, e.g. setting the time zone. These are automatically granted by the system to apps that request them.

  2. Dangerous Permissions: these potentially could violate the user’s privacy or severely affect the user’s stored data or the correct functioning of other apps, e.g. ability to access the user’s contacts. The user must grant an app permission to use them.

  3. Signature Permissions: these are for use by applications signed with the same key (i.e. from the same developer) as the app that defines them. These are automatically granted by the system to apps that request them (provided the signature matches).

  4. Signature Or System Permissions: these are special permissions intended for use by the Android platform itself.

Permission groups

Each permissions can also be included in a permission group. This mostly affects dangerous permissions, as once the user has granted an app permission to use a dangerous permission in a permission group, the app is automatically granted any other dangerous permission it requests from that group.

For example, if the user grants an app permission to read the calendar, and the app subsequently requests permission to write to the calendar, this will automatically be granted as both permissions are in the calendar group.

Runtime enforcement of permissions

If an action is protected by a permission Android will enforce it at runtime. The cases we look at this week are:

  1. Starting an Activity.

  2. Starting, or binding to, a Service.

  3. Accessing a Content Provider.

  4. Sending and receiving broadcasts.

These are all cases where an app developer must be careful to ensure their app does not expose data that it should not, or act on external input that is potentially unsafe.

Remember input validation from last week? It is even better if you can block an attacker from sending you malicious input in the first place!

Share this article:

This article is from the free online course:

Secure Android App Development

University of Southampton

Contact FutureLearn for Support