Since Android got acquired by Google (in 2005) and Google undertook its entire development, a lot has changed in the last 9 years, especially in terms of security. Right now, it is the world's most widely used smartphone platform especially due to the support by different handset manufacturers, such as LG, Samsung, Sony, and HTC. A lot of new concepts have been introduced in the subsequent releases of Android such as Google Bouncer and Google App Verifier. We will go through each of them one by one in this chapter.
If we have a look at the architecture of Android as shown in the following figure, we will see that it is divided into four different layers. At the bottom of it sits the Linux kernel, which has been modified for better performance in a mobile environment. The Linux kernel also has to interact with all the hardware components, and thus contains most of the hardware drivers as well. Also, it is responsible for most of the security features that are present in Android. Since, Android is based on a Linux platform, it also makes porting of Android to other platforms and architectures much easier for developers. Android also provides a Hardware Abstraction Layer for the developers to create software hooks between the Android Platform Stack and the hardware they want it to port.
On top of Linux kernel sits a layer that contains some of the most important and useful libraries as follows:
The following is a graphical representation of the Android architecture from the Android developer's website:
The libraries in Android are written in C and C++, most of which are ported from Linux. One of the major differences in Android compared to the Linux is that there is no libc library here, which is used for most of the tasks in Linux. Instead, Android has its own library called bionic, which we could think of as a stripped down and modified version of libc for Android.
At the same level, there are also components from the Android Runtime— Dalvik Virtual Machine and Core Libraries. We will discuss a lot about Dalvik Virtual Machine in the upcoming sections of the book.
On top of this layer, there is the application framework layer, which supports the application to carry out different kinds of tasks.
Also, most of the applications created by developers only interact with the first and topmost layer, the applications. The architecture is designed in such a way that at every point of time, the bottom layer supports the above layer and so on.
The earlier versions of Android (<4.0) were based on Linux kernel 2.6.x whereas the newer versions are based on kernel 3.x. A list of different Android versions and the Linux kernel they used are specified as follows:
All the applications in Android run under a virtual environment, which is called Dalvik Virtual Machine (DVM). An important point to note here is that from Android Version 4.4, there is also the availability of another runtime called Android Runtime (ART), and the user is free to switch between the DVM and the ART runtime environments.
However, for this book, we'll be focusing only on the Dalvik Virtual Machine implementation. It is similar to Java Virtual Machine (JVM), apart from features such as it is register-based, instead of stack-based. So, each and every application that runs will run under its own instance of Dalvik Virtual Machine. So, if we are running three different applications, there will be three different virtual instances. Now, the point to focus here is even though it creates a virtual environment for the applications to run, it shouldn't be confused with a secure container or a security environment. The prime focus of the DVM is performance-related, and not security-related.
The Dalvik Virtual Machine executes a file format called .dex or Dalvik Executable. We will look more into the .dex file format and will analyze it in the upcoming chapters as well. Let's now go ahead and interact with adb, and analyze an Android device and its architecture more deeply.