From Android Wiki
|Line 26:||Line 26:|
Latest revision as of 08:47, 31 January 2013
Sandboxing means that apps installed on an Android device are carefully controlled in what they can do to the system and to each other: each app is running in its own “sandbox”, where it is pretty much free to play and make a mess, with minimal impact on the kids in the other sandboxes.
Android runs on the Linux kernel, which has built-in multiuser support. However, an Android device is not designed to be shared among multiple users. Instead, Linux user IDs are assigned to each installed app (uniquely among all currently-installed apps on a particular device), and used to enforce privilege separation among them.
On top of this, each app has to have a manifest in which it declares what permissions it needs: these are displayed to the user before they can download the app from the Android Market (and hopefully by installers for alternative app marketplaces as well).
As of Android 4.0, the android.Manifest.permission class lists 122 separate permissions that an app can request of the system.
Permissions are not just to control what functions apps can ask the system to perform; apps can also use these to control what services they are asked to perform on behalf of other apps. An app can define its own permissions, which other apps can then request in <uses-permission .../> entries in their manifests.
For example, the Launcher is just another app, but it demands special permissions that apps must request before they can send it requests to create or delete shortcuts.
Unfortunately, some proprietary app developers have a habit of requesting long lists of permissions that their apps don’t really need. This aggravates the situation of confirmation fatigue, where users become accustomed to blindly clicking OK without reading what the message might be warning them about. And then authors of malware have exploited this blindness to distribute their software via the Android Market, where it might get downloaded thousands of times before somebody thinks to question the suspiciously-long list of permissions.
Some permissions are considered so potentially damaging, that they are not available to ordinary apps. Instead, they can only be granted to apps signed with the platform key, which is controlled by whoever provided the Android build running on the device—i.e. usually the device vendor. One example is SET_TIME, which lets the app set the system clock.
You can see the full list of permissions and their levels in the source file frameworks/base/core/res/AndroidManifest.xml—the extra-sensitive ones have their android:protectionLevel attribute set to "signature" or "signatureOrSystem".
It seems to me that the existence of such permissions represents a double failure of the sandboxing concept. First of all, the user is not to be trusted to be allowed to install apps that are granted these permissions, and secondly the device vendor abrogates to themselves the powers represented by these permissions, giving the user no choice in the matter.