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!

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:

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.