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.
Android application structure
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_COMPLETED
after 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.