Android Platform Architecture

About 53% of the smartphones around the world contain Android, while about 44% contain IOS. 

This fact together with the constant increase of the smartphone use, makes the Android platform a great target for researchers and hackers. 

However, there is no really organized article about the Android platform (I couldn't find any). So I decided to write this article, describing the platform's layers and detailing about them.

Platform Architecture

The Android platform is a open source Linux-based platform. It created for a wide variety of devices, including smartphones, tablets and TVs.

The platform can be break into layers, according to the next diagram : 

Figure 1. Android platform's layers

Linux Kernel

The foundation of the Android platform is the Linux kernel.

The Android's Linux kernel has ARM architecture, which is 32bit architecture (except ARM8 which supports 64bit architecture) that was designed for RISC processors. The ARM arcitecture implemented in most of the smartphone processors, like in Qualcomm's Snapdragon, Samsung's Exynos and Hummingbird, and even at Apple's A4 and A5.

It provides the basic system functionality, such as process, device and memory management, alongside with device drivers, making it easier to interface peripheral devices.

In addition, the Linux kernel provides security features to the platform :

• User-based permission model.
• Process isolation.
• User resources isolation.
• Extensible mechanism for secure IPC (inter-process communication).
• An ability to remove unnecessary and/or unsecure parts of the kernel.

Furthermore, the Linux kernel also provides ASLR, NX and stack protector which make the executables much more secure and harder to exploit.

Nowadays, the AOSP (Android Open Source Project) uses the Linux kernel 3.16.1 for Lollipop, 3.18.10 for Marhmallow, abd 4.4.19 for Nougat. However, it doesn't necessary that those kernel-platform versions match will be held.

Harware Abstraction Layer

The HAL (Hardware Abstraction Layer) provides interfaces between the hardware components to the Java API Framework layer. 

The HAL is a C/C++ layer which contains shared libraries (.so & .h files) for each hardware component. Each library (equivalent to device driver) is a vendor specific implemented. When a call to access device hardware, the Android system loads the correct library, according to the wanted component.

Each hardware interface has properties defined in: 

hardware/libhardware/include/hardware/hardware.h

This file guarantee that HAL interfaces will have predictable structure. In addition, it enables the Android system to load HAL interfaces according the version specified in the structure.

In general, there are 2 components to a standard HAL interface :

• Module - represents the HAL implemention (which stored at the .so file). It contains prototpyes of functions, and another struct object called hw_module_t. The hw_module_t contains metadata about the module (version, name, author and etc), and a pointer to the "open" functions of the module - functions which used for initiating the communication with the hardware component.

• Device - abstracts the actual hardware component (i.e, an audio module can contain the primary, USH or Bluetooth audio component). As the module, the device contains a struct object which contains pointers to more hardware-specific functions.

On the device, the HAL libraries can be in 2 different location :

• /system/lib/hw/
• /vendor/lib/hw/

Android Runtime

Prioir to the Android 5.0 (Lollipop) Dalvik was the Android runtime. However, since the Lollipop platform published, and new Android runtime was introduced called ART (Android RunTime).

Replacing the Dalvik, which is the discontinue process vitrual machine, the ART performs a translation of the app's bytecode to native instructions, that are later executed by it.

Figure 2. A comparison of ART and Dalvik

 

The main features the ART provided are :

• AOT & JIT compilations - the combination of AOT & JIT compilations improves the runtime performance, saves storage space and speeds up updates (system and apps wise). The AOT compiler will basically compiles .oat files when they need to be installed. The JIT will compile .dex files which belong to app update or recompilation of an app during OTAs. The AOT & JIT compilers use the same compiler. However, they use different set of optimizations. 

• Improved garbage collection - GC (garbage collection) can cause affect performance, resulting poor UI or bad display. The GC of ART is improved by less pauses, adding the ability to Parallelized processing, better priority management, better timing (including concurrent collections) and more compact by size (to reduce background memory usage).

•  Better debugging support - new debugging features introduced with the ART, like sampling profiler, improved diagnostic details during a crash or exceptions, and the ability to add watchpoints in order to monitor specific fields.

Native C/C++ Libraries

Many core components of the Android system written in native code, which require native libraries, written in C/C++.
Some of the native libraries are : 

• LIBC - like Linux OS.
• Webkit - the browser engine.
• OpenGL - 3D graphics rendering.
• Media Framework - provides diffrenet meida codecs.

The libraries can be found on the device at /system/lib/ or /system/lib64/.

Java API Framework

This layer is 1 of the most important layers for the average Android app developer. 

This layer provides the entire features available in the Android OS. These Java APIs provide to the developer the "building blocks" he/she needs for creating apps by simplifying the reuse of core, modular system components and services.    

The application framework manages the basic operations of an Android device such as resources, voice call and SMS management. The most important "blocks" the framework provides are :

• Activity Manager - used to manage the complete activity (GUI screen) life cycle of apps.

• Content Providers - used to manage the data sharing between 2 apps.

• Telephony Manager - used to manage all the telephony operations - such as voice calls and SMSs.

• Location Manager - used to manage the location obtains using GPS or BTS.

• Resource Manager - used to manage the different resources using in an app.

System Apps

Android comes with a set of apps SMS, calendars, internet browsing, contact management and etc. 

The system apps function both for users interaction, and for providing key capabilities that the developers can access from their own app.

It's important to mention that the system apps have no special among the apps (including the third party apps). So, third party apps can be used instead of the system apps (i.e for browsing the internet).

P.S - I didn't detailed much about the the Java API Framework and the System Apps layers. I have more interest in the low level stuff, because I see those as more vulnerable.

Resources : 

• http://expandedramblings.com/index.php/android-statistics/
• https://developer.android.com/guide/platform/index.html
• http://www.c4learn.com/android/android-os-architecture/
• https://en.wikipedia.org/wiki/Android_version_history
• https://source.android.com/security/overview/kernel-security.html
• https://en.wikipedia.org/wiki/ARM_architecture
• https://www.e-consystems.com/blog/linux-android/?p=783
• http://source.android.com/devices/index.html
• http://source.android.com/devices/tech/dalvik/dex-format.html
• https://en.wikipedia.org/wiki/Just-in-time_compilation
• https://en.wikipedia.org/wiki/Ahead-of-time_compilation
• https://en.wikipedia.org/wiki/Dalvik_(software) 
• https://en.wikipedia.org/wiki/Android_Runtime