Android is a modern operating system with a layered software stack. The following figure illustrates the layers in Android's software stack. This software stack runs on top of the device hardware. Android's software stack can run on many different hardware configurations such as smartphones, tablets, televisions, and even embedded devices such as microwaves, refrigerators, watches, and pens. Security is provided at every layer, creating a secure environment for mobile applications to live and execute. In this section, we will discuss the security provided by each layer of the Android stack.
On top of the device hardware sits the Linux kernel. The Linux kernel has been in use for decades as a secure multi-user operating system, isolating one user from the other. Android uses this property of Linux as the basis of Android security. Imagine Android as a multi-user platform where each user is an application and each application is isolated from each other. The Linux kernel hosts the device drivers such as drivers for bluetooth, camera, Wi-Fi, and flash memory. The kernel also provides a mechanism for secure Remote Procedure Calls (RPC).
As each application is installed on the device, it is given a unique User Identification (UID) and Group Identification (GID). This UID is the identity of the application for as long as it is installed on the device.
Refer to the following screenshot. In the first column are all the application UIDs. Notice the highlighted application. Application com.paypal.com has the UID app_8 and com.skype.com has the UID app_64. In the Linux kernel, both these applications run in their own processes with this ID.
Refer to the next screenshot. When we give the id command in the shell, the kernel displays the UID, GID, and the groups the shell is associated with. This is the process sandbox model that Android uses to isolate one process from the other. Two processes can share data with each other. The proper mechanics to do so are discussed in Chapter 4, Defining the Application's Policy File.
Although most Android applications are written in Java, it is sometimes required to write native applications. Native applications are more complex as developers need to manage memory and device-specific issues. Developers can use the Android NDK toolset to develop parts of their application in C/C++. All native applications conform to Linux process sandboxing; there is no difference in the security of a native application and Java application. Bear in mind that just as with any Java application, proper security artifacts such as encryption, hashing, and secure communication are required.
On top of the Linux kernel sits the middleware that provides libraries for code execution. Examples of such libraries are libSSL, libc, OpenGL. This layer also provides the runtime environment for Java applications.
Since most users write their apps on Android in Java, the obvious question is: does Android provide a Java virtual machine? The answer to this question is no, Android does not provide a Java virtual machine. So a Java Archive (JAR) file will not execute on Android, as Android does not execute byte code. What Android does provide is a Dalvik virtual machine. Android uses a tool called dx to convert byte codes to Dalvik Executable (DEX).
Originally developed by Dan Bornstein, who named it after the fishing village of Dalvik in Iceland where some of his ancestors lived, Dalvik is a register-based, highly optimized, open-sourced virtual machine. Dalvik does not align with Java SE or Java ME and its library is based on Apache Harmony.
Each Java application runs in its own VM. When the device boots up, a nascent process called Zygote spawns a VM process. This Zygote then forks to create new VMs for processes on request.
The main motivation behind Dalvik is to reduce memory footprint by increased sharing. The constant pool in Dalvik is thus a shared pool. It also shares core, read only libraries between different VM processes.
Dalvik relies on the Linux platform for all underlying functionality such as threading and memory management. Dalvik does have separate garbage collectors for each VM but takes care of processes that share resources.
Dan Bornstein made a great presentation about Dalvik at Google IO 2008. You can find it at http://www.youtube.com/watch?v=ptjedOZEXPM. Check it out!
Application developers developing Java-based applications interact with the application layer of the Android stack. Unless you are creating a native application, this layer will provide you with all the resources to create your application.
We can further divide this application layer into the application framework layer and the application layer. The application framework layer provides the classes that are exposed by the Android stack for use by an application. Examples include the Activity manager that manages the life-cycle of an Activity, the package manager that manages the installing and uninstalling of an application, and the notification manager to send out notifications to the user.
The application layer is the layer where applications reside. These could be system applications or user applications. System applications are the ones that come bundled with the device such as mail, calendar, contacts, and browser. Users cannot uninstall these applications. User applications are the third party applications that users install on their device. Users can install and uninstall these applications at their free will.
To understand the security at the application layer, it is important to understand the Android application structure. Each Android application is created as a stack of components. The beauty of this application structure is that each component is a self-contained entity in itself and can be called exclusively even by other applications. This kind of application structure encourages the sharing of components. The following figure shows the anatomy of an Android application that consists of activities, services, broadcast receivers, and content providers:
Android supports four kinds of components:
Activity: This component is usually the UI part of your application. This is the component that interacts with the user. An example of the Activity component is the login page where the user enters the username and password to authenticate against the server.
Service: This component takes care of the processes that run in the background. The Service component does not have a UI. An example could be a component that synchronizes with the music player and plays songs that the user has pre-selected.
Broadcast Receiver: This component is the mailbox for receiving messages from the Android system or other applications. As an example, the Android system fires an Intent called
BOOT_COMPLETEDafter it boots up. Application components can register to listen to this broadcast in the manifest file.Content Provider: This component is the data store for the application. The application can also share this data with other components of the Android system. An example use case of the Content Provider component is an app that stores a list of items that the user has saved in their wish list for shopping.
All the preceding components are declared in the AndroidManifest.xml (manifest) file. In addition to the components, the manifest file also lists other application requirements such as the minimum API level of Android required, user permissions required by the application such as access to the Internet and reading of the contact list, permission to use hardware by the application such as Bluetooth and the camera, and libraries that the application links to, such as the Google Maps API. Chapter 4, Defining the Application's Policy File, discusses the manifest file in greater detail.
Activities, services, content providers, and broadcast receivers all talk to each other using Intents. Intent is Android's mechanism for asynchronous inter-process communication (IPC). Components fire off Intent to do an action and the receiving component acts upon it. There are separate mechanisms for delivering Intents to each type of components so the Activity Intents are only delivered to activities and the broadcast Intents are only delivered to broadcast receivers. Intent also includes a bundle of information called the Intent object that the receiving component uses to take appropriate action. It is important to understand that Intents are not secure. Any snooping application can sniff the Intent, so don't put any sensitive information in there! And imagine the scenario where the Intent is not only sniffed but also altered by the malicious application.
As an example, the following figure shows two applications, Application A and Application B, both with their own stack of components. These components can communicate with each other as long as they have permissions to do so. An Activity component in Application A can start an Activity component in Application B using startActivity() and it can also start its own Service using startService().
At the application level, Android components follow the permission-based model. This means that a component has to have appropriate permission to call the other components. Although Android provides most of the permissions that an application might need, developers have the ability to extend this model. But this case should be rarely used.
Additional resources such as bitmaps, UI layouts, strings, and so on, are maintained independently in a different directory. For the best user experience, these resources should be localized for different locales, and customized for different device configurations.
The next three chapters talk about the application structure, the manifest file, and the permission model in detail.