Contact FutureLearn for Support
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.

Android application sandbox

In this section, we introduce you to Android’s security architecture and give you an overview of permissions. In an exercise, you will also be encouraged to practice fixing the permissions vulnerabilities in BuggyTheApp.


Android is built upon the Linux kernel. Linux is an open source operating system that runs on devices, from something as small as a mobile phone (in the case of Android), through to the largest of super computers.

Under Linux, processes belong to users, where each user has a unique user ID (UID). The operating system prevents a process belonging to one UID from reading the files and data belonging to another UID, unless the second UID has explicitly shared the data with the first UID.

Android takes this further. Rather than each UID belonging to a distinct person, e.g. multiple users logged into a server, in Android each app is given a unique UID.

From the perspective of the Linux kernel, each Android app corresponds to a distinct ‘user’. This makes sense as each Android device only has one real physical user (mobile phones don’t have multiple login accounts and simultaneous users!).

Note for Nerds: two apps that are signed with the same key (i.e. from the same developer) can share a UID if, at installation, they both request this. Apps that share a UID can read and write to each other’s files.

This separation of apps into different UIDs provides the main security mechanism of Android. Each app by virtue of its unique UID is sandboxed from other apps. Other apps are prevented by the Linux kernel from accessing its memory, or reading and writing its files (by default files created by an app are not globally readable or writeable).

This is an example of the Principle of Least Privilege; each app can only access its own memory and files.

Note for Nerds: Dalvik (Android’s VM 1), unlike JVMs or the .NET runtime, the Dalvik VM is not a security boundary as Dalvik can interoperate with native code. The security boundary is the Android Application Sandbox, i.e. security is enforced by the Linux kernel, not by Dalvik.


  1. Since Android 5.0 Dalvik has been replaced by the Android Runtime (ART), which is a new virtual machine with Ahead-of-Time (AOT) compilation, and improved garbage collection. 

Share this article:

This article is from the free online course:

Secure Android App Development

University of Southampton