turtletramp's blog

Android - Security Overview

Focusing mainly on topic relevant if you intend to build your own OS build and need to understand how it works to being able to extend it on demand.


There are 2 main perspectives at which you are looking at the topic Security in Android:

    1. you want to know how you can control access to your app from other apps
    2. you want get access to system / Android OS services to build your great app.
  2. As a SYSTEM DEVELOPER who is building a new Android OS system for a defined hardware environment
    1. you want to have full control what apps are alowed to do and what not
    2. you want give your own system applications full access to the system
    3. and maybe more :) ... who knows how many ideas are coming up when you have the full freedom ;)

In my article I will focus on the second one; the SYSTEM DEVELOPER.

For a component overview see https://source.android.com/devices/tech/security/images/image00.png


Here we are talking about "Physical Users" which is actually working with an Android device. What we do not talk about here are Linux users created inside the Android system as typically every installed app get's a separate Linux user (UID) assigned as part of the application sandbox.

Per default an Android system is a single user system. But with Android 4.2 also multiple physical users (humans) are supported. To activate this the following must be changed:

  • edit frameworks/base/core/res/res/values/config.xml
  • set the "config_multiuserMaximumUsers" to something greater then 1. For example if you want to support 4 different possible human users on this device set this value to 4.
  • each user get's a specific data directory at /data/user/ where all of the apps data is stored.
  • When user switching is done the users data folder under '/data/user/<user-id> is symlinked to /data/data/'' so that independent from the current user any app will find it's user specific data under the same /data/data/ directory.

When this is configured you will find a new directory on the data partion at /data/system/users holding information about the available users.
On a single user device we would always have the user with id 0.

What you can do is:

  • enable / disable packages per user
  • when an app is installed it get's now a different assigned UID: 100000 * <user-id> + <app-user-id> (the 100000 comes from AID_USER in system/core/include/private/android_filesystem_config.h

Filesystem / Partitions

  • RO /system; does not include any user data
  • RW /data; all apps, all data of all apps (also from the system apps)
    • /data/app: user apps (apk = application package; odex = optimized for the target device)
    • /data/data: all data of all applications (user + system) is stored here
  • RW /sdcard: freely accessible to everybody; for writing the user is asked (?)
  • RW /cache: contains transient user data (e.g. browser cache)
  • RO /: contains the init process

Platform keys

(?!? TO BE CHECKED IF THIS IS REALLY CORRECT, currently only an asssumption ?!?)

See also this interessting discussions:

An Android system typically includes a set of platform keys. If apps are signed with one of these keys the can gain special permissions.

Characteristics (see also https://www.youtube.com/watch?v=NS46492qyJ8 from marakana.com):

  • per default (AOSP) these are stored at build/target/product/security/
  • There are typically 4 types:
    • platform: used for core parts of the system of AOSP (framework core, BackupRestoreConfirmation, DefaultContainerService, SettingsProvider, SharedStorageBackup, SystemUI, VpnDialogs,, Bluetooth, CertInstaller, KeyChain, Nfc, PackageInstaller, Phone, Provision, Settings, Stk, TelephonyProvider, ...)
    • shared: used to sign home/contacts part of AOSP (Contacts, Launcher2, QuickSearchBox, LatinIME, PinyinIME, ApplicationsProvider, ContactsProvider, UserDictionaryProvider, built-in live wall papers
    • media: used to sign media/download framework parts of AOSP (Gallery, DownloadProvider, DrmProvider, MediaProvider
    • testkey: used to sign everything else (default for packages that do not specify one of the keys above (in Android.mk file: LOCAL_CERTIFICATE := ...)

Applications / Apps

There are 2 main types of applications:

  • System / pre-installed Applications
  • User-installed Applications

Every app that is running is embedded inside a sandbox that is built up on 2 major components:

  • each app is a separate linux process
  • each app runs it's owne instance of the Dalvik VM

User installed apps

  • Typically each installed has it's own UID. So it cannot access data of another installed app as the Kernel would not allow access to data of another UID. The UID is defined during the installation process.
  • An application can only be installed if it is properbly signed. The goal of signing an user application is continuity. If once an app is installed only the author of the original app is able to update it.
  • If several applications use the same key to be signed they have the option to share the same UID. For details see here.
  • For updating an app (defined by equal package names) it is checked if their public key match. If so the new app is allowed to overwrite the original one.
  • The app signature is only checked during installation / update but not at app startup.

The Filesystem

Helpful Links



App Development