- Android Development: Database Upgrades
- Android Development: Missing API
- (Not) Integrating Application with Intents
- Android Activity Lifecycle
- URI Matching in Android’s IntentFilters
- Android Intent Sender Verification
- Android Jittery Scrolling Gallery
- Encryption on Android & BouncyCastle
- Android Permission Handling
- ContentProvider Curses Cursor
- ContentProvider Wasted Potential
Android includes a system for granting permissions that’s quite flexible and great in many ways. In other ways, it’s terrible. Let me run you through that.
Access Control Basics
When we’re talking about permissions, it makes sense to briefly talk about access control — that is, authorization in security terms1. Access control is a term very much used in the context of file systems, and it’s that context that also illustrate just how simple or complex you can make things:
- Primitive file systems may have no access control, and everybody can read, write and modify anything.
- Not even the old DOS file system is that primitive: files here have attributes, and the attributes determine whether or not you can e.g. write to a file. Unfortunately, DOS has no concept of authentication, therefore everyone also has the right to alter file attributes, making the DOS file system unsuitable for actual access control. If you have access to the access control system, you have access to everything.
- UNIX file systems include a simple authentication component, in that in addition to attributes, files also have an owner and a user group. There are then three groups of attributes: one set for the owner, one for the group, and one for everyone who is not the owner nor in the group. UNIX systems also include the concept of a superuser who has access to everything at all times. With that, a lot of access control management is possible.
- More advanced UNIX file systems then contain something called access control lists (or ACLs for short). They’re some extended meta-data that can list attributes for more individual users or user groups, finally allowing for very fine-grained control over who to grant access to which file.
But there’s one thing not even the most complex of ACL-based systems offer: the attributes that can be set per individual or group are fixed and have fixed semantics: you can read, write, or execute a file, or any combination of those bits. There’s (usually) no way to, say, allow appending to a file but no other write access.
This is a design choice in file systems, and you can argue all day about whether or not it’s good. The important points to take away are:
- The amounts of different types of access are regulated by the operating system.
- The semantics of what a given access type means are regulated by the operating system.
From a certain point of view, that’s also as it should be: after all, files are resources under the operating system’s control, and it only makes sense for the entity that has control to manage how to grant access to other participants in a system.
Android Permissions: The Good
Android’s designers have realized that they’re not so much dealing with access to data in their operating system, but with access to functionality. As the software that provides a given functionality is controlled by third party contributors, and the software that makes use of such functionality is controlled by a third party, there is simply no way to predict all the different means by which these software packages might interact.
Therefore, in Android, the semantics of a permission are not pre-determined by the operating system.
Instead, a permission in Android is nothing but a free-form string2 and some meta-data:
- The free-form string acts as an identifier for the permission.
- The meta-data acts as a description to the end user of the semantics of the permission.
As an example of the above, the android.permission.INTERNET permission grants applications to use networking sockets, and thereby also access the internet (if an internet connection exists).
Now this particular example isn’t necessarily the best because the permission is defined and enforced by the Android operating system. But it’s equally possible for one app to require a newly invented permission from another app before it decides to do something.
Permissions also don’t just grant themselves: the user of a phone explicitly grants permissions to apps they’re using, thereby gaining control over how much trust they assign to software packages.
- Authentication establishes who you are, authorization what you’re allowed to do. It’s generally best to consider the two as separate things. [↩]
- There are conventions to how the string is to be formed, but they’re not enforced by the operating system [↩]


