Android…The theory of everything
Android platform architecture, as simple as it should be
Hi devNation! I am Azzeddine CHENINE, Software Engineering Student, Google Dveloper Group, Algiers Co-orgnizer and an Android Developer who has been digging into this awsome Google product for nearly 2 years now.
During All this period and as any new Android Hacker, I was enjoying coding my first applications, getting advantage of the amazing SDKs and tools provided by the Android team. Until I was asked a question during a job interview by Fares Othmane Mokhtari and I quote :
“From an Android Engineer prespective: How do you define/describe Android and can you break-down its architecture ?”
I somehow answered these two questions, but I wasn’t satisfied, I knew that my answers were missing some details.
“Code is our passion, Engineering is our profession”
As Engineers, we are professional thinkers, we talk facts and facts don’t leak details. So, In this blog, we will be diving inside the 2 Billion monthly active users platform, answering all the questions that I‘ve montioned.
How do you define Android ?
Android ;in fact; is more than just an operating system, it is a mobile platform provided by Google, which consists of:
- Operating System ( Linux Kernel 3.6).
- Middleware (a set of libraries provided by Google).
- Key applications ( Intagram, Facebook, Gmail, Angry birds …etc).
Someone will say : “Why do we need the use of a Kernel 🤔 ?”
I got ya 🤗 . If we take any electronic device, it consists of two things:
- Hardware components
- Software components
So, an Android device will need a middle layer (Operating System) to provide a level of abstruction between these two components and handle a pure multitasking environment.
But wait a sec 😒, why linux ?
Android is Open Source 😌, it was build so any manifacture can access it, adapt it to a style of choice and run it on any platform (mobile, watch, auto…etc). Therfore, we will be no longer tied to a single company’s ecosystem (🙈🍎).
Can you break-down Android’s architecture ?
As mentioned before, Android is a linux based software stack. Its architecture can be explained with the following diagram:
1 — Linux Kernel:
Since 2010, Google has maintained its own forked version of the Linux Kernel sepecifically for Android.
As the lowest layer above the device CPU, the linux kernel is responsible of the main activities of any operating system which can be sum-up in 4 points:
- Memory management: it is the process of controlling and coordinating device memory by assigning suitable memory blocks to various running programs.
- Resource management: it refers to the device available resources and how it can be perfectly allocated to the running processes to optimize overall system performance.
- Driver management: The main purpose of device drivers is to provide abstraction by acting as a translator between a hardware device and the operating system, helping in running atached hardware ( display, WI-FI and audio).
- Power management 😌.
2 — Hardware Abstraction Layer:
the HAL defines a standard interface for hardware vendors to implement inorder to be exposed to the higher level Java-API.
It consists of multiple library modules for a specific type of hardware components (Bluetooth, Camera …etc), so that it can be loaded when it gets called by the framework API.
3 — Android Runtime:
As noted, the Linux Kernel provides a suitable multitasking environment, allowing multiple process to execute concerntly.
Ok, let me guess 🤔 , each Android application is a single process running on the linux Kernel 🤓 ?!
Not exactly 🤗! Android System runs each application as a single process inside a dedicated virtual machine instance called Dalvik Virtual Machine (DVM).
the DVM was developed by Google to be more efficient than the JVM(Java Virtual Machine) when it comes to running multiple instances inside a limited resources environment like a hand size mobile device.
Wait, wait …wait ✋,why do we need a virtual machine instance for each app 😏 ?!
In fact, providing a VM instance for each running application will ensure the following important points:
- Applications will not in anyhow interfere with each other or the operating system.
- Applications will have restricted permissions when it comes to direct access to the device hardware.
- Applications running process will not be tied to any specific set of hardware.
In order to run the code inside the DVM, the app code must be compiled from standard Java code (.java file format) to Dalvik byte code (.dex file format). After that, the code will be compiled for the second time to machine binary code.
speaking about Machine Code…Let’s talk a bit about Android compilation 😋!
Google has been working hard to enhance this process. Two compilation strategy were introduced until now:
- Just In Time : when you run the app, only the required code for execution will be compiled to machine code just in time.
And as the app progress, additional code will be compiled and cached. This code caching strategy will provide a small memory footprint and less allocated space for the app.
The JIT mechanism was adopted due to the type of mobile devices available that time (before 2013 we don’t have 6 Gig of RAM phone 😛).
- ART: starting from Android Kitkat and unlike JIT compilation, the app Dalvik byte code is pre-compiled during the app instalation. Therefore, we will benefit from a faster app loading and execution time.
Moreover, due to the fact that the code is compiled just for one time, we will have less CPU usage by the app on run time ⇒ Less battery drain 🔋 💪🏼.
Android Runtime core-libraries:
It falls into three main parts:
- Dalvik VM libraries: used to interact and operate with the Dalvik virtual machine instances and it is mostly not available for developers to use.
- Java libraries: Since Android applications are mainly developed with the JAVA programming language, the use of JAVA libraries is a must.
These libraries provide support for elementary development tasks such as: Strings, Network and files handling, regardless of the platform (don’t worry about Kotlin 😉, it is also designed to run over the JVM).
3. Android Libraries: a set of JAVA-based libraries that is used specificly for Android development like : views, database access and media controlling…etc .
4 — Native C/C++ Libraries :
the previous Android Runtime libraries are the main interface for Android Developers to write Android code. Otherwise, most of the platform core tasks (2D and 3D graphics, Secure Socket Layer, SQLite database system, media ..etc) are handled by native C/C++ based libraries.
In most cases, a regular Android developer will only access these libraries using the JAVA wrapper methods (you can access OpenGL ES through the Android framework’s Java OpenGL API). But, if you want to go pro, you can use the Android NDK (Native Development Kit) where you can call C/C++ methods within JAVA code using JNI (Java Native interface).
5 — Application framework:
The application framework provide a full set of AndroidOS features to Developers as a JAVA Api.
These features are the main building blocks for any application:
- View System
- Resource Manager
- Notification manager
- Content provider
6 — Systeme Apps :
the set of native apps that comes with the device (Alarm, Contact, Camera…etc) or the ones the user installs.
As a recap, this paragraph from Android Studio essentials book will do the work for us:
“Android is implemented in the form of a software stack architecture consisting of a Linux kernel, a runtime environment and corresponding libraries, an application framework and a set of applications. Applications are predominantly written in Java and run within individual instances of the Dalvik virtual machine.”
As a conclusion, as Developers/Engineers, a better understanding for the platform where we are deploying our apps, will lead to a more efficient, reliable and platform resources aware applications.
I hope you like this article. Any feedback or questions will be more than welcomed.
Thanks for reading 🙏🏻, Peace🎙✌️!
More where this came from
This story is published in Noteworthy, where thousands come every day to learn about the people & ideas shaping the products we love.
Follow our publication to see more product & design stories featured by the Journal team.
