Introduction to Android Operating System
The Android Operating System is an open-source system. Many people say it is Linux, but that is not fully true. Though Android has kernels which are similar to that of Linux, that is the only thing that is similar. Today, we will be taking a deeper look into the insides of the Android Operating System that is the processes, the framework, and other similar structures. So, let’s get started from the very basics and have a look till the inner root of the Android Operating System.
After the release of iPhone and Windows Lumia Series i.e. the Microsoft Windows related phones, Google wanted to do the same. But they wanted something that could be open source. The main reason behind this was so that anyone could debug it, modify it any changes as they wanted. Then came the idea of Linux. Linux is a fully open-source operating system and it is widely accepted by the community all over the world. It is one of those operating systems which is used even more than Windows or Mac OSX. Besides, Linux has the capability to run almost every other thing that could be run on either Mac or Windows. Thus, Google decided to develop an Operating System for a Cell phone with the same basic inner shell as that of Linux, so that it is compatible with almost everything and the outer shell would be developed as, when and also how it’s required.
Android Operating System as an Open Source Project (AOSP)
Android has the ability to freely modify, invent and implement our own device drivers and features. Now to speak of, there are five different layers of an Android Operating System. It goes as follows:
As you can see in the above image, the first layer is the Application Framework, the second being the Binder IPC Proxies, the third consists of the Android System Services, fourth is the HAL or the full form being Hardware Abstraction Layer, and the last being the Linux Kernel. Now as I said previously, you can see that the only part of the Linux which an Android Operating System consists of is the Linux Kernel. Now let’s have a look into all of them one by one.
Android Application Framework
This App Framework is used by app developers for Android. This part of Android has at the very least to do anything with the hardware layer. Android Applications are programmed in Java language. After programming an app, the Android SDK tools help to compile the data and the resource files such as the XML files, the jar files, manifest files, and other images and stuff into one single archive package with a ‘.apk’ extension. This apk file can be used to install the app with just a single click on the Android Devices. Now, since the Android Operating System behaves like a Linux Environment, the app behavior is also the same here. Each app is considered as a separate user from the other and runs in its own Virtual Machine. This makes the programmed code of the app isolated and also prevents it from getting infected from others unless explicitly stated. Every other app has its own USER ID and every other process has its own Virtual Machine.
The Android Application Framework works on the Principle of Least Privilege. Least Privilege Principle means that whenever a new app needs to run, but there is no available memory, the Android system will automatically quit the old application which is not necessary to run in the background. This is one of the best parts of Android Operating System security. This principle makes it possible each app has only that access which is required to do its work. Thus an app cannot get permission for what is not intended to do. This, in turn, creates a very secure environment within the Android operating system itself.
4.5 (2,876 ratings)
Binder IPC is known as Binder Inter-Process Communication. This interface allows a programmer to make an application to communicate with other applications. More often, it’s not the applications that communicate, it’s the processes. Binder IPC helps to run multiple processes at the same time on a concurrent level. This binder implementation is sourced through the Kernel of the Android Operating System. Now there have been questions raised as to why does the binder needs to stay in the kernel, and why can it not run from the Linux IPC mechanisms? The main reason for that is because the binder avoids using the unnecessary allocation of space unlike other IPC mechanisms in the Linux System. If you have heard of the term ‘magic in python’, then that is what a Binder IPC would look like to an Application developer, since it is totally hidden from them, and it simply appears to work, unlike the High-level framework where you need to make it work it explicitly. This actually enables the high-level framework to communicate with the android operating system services.
System Services of Android Operating System
A service is a compiled piece of code that runs for a long time in the background of an android operating system without giving any interface. Any application, may it be user or system can start a service, but it will still keep running in the background even if the application is closed. However, there are two types of services:
Started services usually start when an application calls for it. However, a Started type of service usually does only a single operation and does not return anything.
Bounded services offer a client-server relation interface. Bound service runs till the foreground application runs and then it is stopped once the application activity is destroyed.
The system services of android provide necessary information to the user applications in order for them to work properly. And these communications between the system services and the user applications are done with the help of the Binder IPC from the Kernel. Now it may come to surprise, but not all applications in an Android are written in Java. Some of them are written in C and C++. Those applications which need to be in near contact with the hardware are written in C and C++. The main reason for this is because most of the time the system services need to be in constant contact with the hardware. This makes it important for the compiled piece of code to be extremely fast. And when it comes to hardware acceleration and high performance, C is much more faster than Java or any other language out there.
Hardware services that are in constant use, for eg: Proximity sensors, accelerometer or the touch screen need to be written in C. Other hardware like the Camera or the sound mostly makes use of the JNI calls. Thus if you ever notice, the touch screens will always be faster than launching a camera or playing a song via a music player.
When creating a System service, make a note that services tend to run in the main process and it does not create a separate process. In short, if your code is going to do some CPU and GPU intensive work, for example, High definition games, then you should prefer creating new threads in the same service; else there will always be a high chance of having “App Not Responding” dialogue box.
Hardware Abstraction Layer
HAL or Hardware Abstraction Layer is specifically designed for vendors. Application developers have little or almost nothing to do here. This layer helps to insert functionality without having any modifications to the system. Every other system has a differently designed HAL since they are made device-specific. HAL consists of two typical structures: Module and Device.
The module structure in HAL is stored as a shared library in .so format which consists of the basic metadata such as the version number, author who designed the module and similar stuff. The Device structure is the actual hardware of the product. Similar to that of the module, but the device structure defines a more comprehensive version of the generic hardware information which contains pointers and other similar stuff that are special to every hardware.
In Linux, applications communicate with the underlying hardware through system calls. But in an Android Operating System, the applications communicate with the hardware via Java APIs.
Compiling a Linux kernel for an Android Operating System is similar to that of compiling it for a basic Linux OS. The only difference is that the Android version is a bit more advanced than that of Linux. The main reason being the android kernel consists of additional features such as the wakelocks, double-tap to unlock and other similar features embedded into the mobile operating device. Features such as wakelock are important since the kernel is going to work on a portable device and it needs to be a bit more aggressive in memory and battery management; unlike the basic Linux where energy management is not an issue. These additional requirements are induced in the kernel rather than the system since these things should not affect the built-in drivers.
Whenever you hear a person saying ‘its Linux’, they usually mean the kernel since it is the most basic still the most important part of any operating system. The main reason why android is based on Linux kernel is that its open source. Anyone can go ahead and modify the Linux kernel without any hardware limitation or even any royalty issues.
Difference between Linux vs Android
So now we have finally reached the most confusing stage of this blog: Linux vs the Android. People usually consider android as a Linux distribution, but I would say that they are only 50% right. Whenever the android operating system boots, it basically loads the kernel like any other Linux distribution, but the rest of the software is totally different from that of Linux. Linux applications won’t run on android and also vice versa unless they are compiled in a chroot environment. The libraries present in typical a Linux distro and Android are totally different from each other. Basically you cannot gain access to the root terminal in Android like that in the case of Linux. This is the main reason why people usually install Busybox, SuperSU, and its binaries after rooting so that they have a more detailed command-line access to the kernel and the shell. There is no default shell in Android, but you can get one by installing a terminal emulator from google play store. Terminal Emulator looks like this:
The android runtime works on a Dalvik Virtual Machine. This Dalvik VM is actually an interpreter for the Java programming language. The whole android runtime is written in Java in Android, and since all applications of android are written in Java it becomes much easier and smooth for the applications to run in the virtual environment. And since all of the Applications and even the runtime is written in Java, it becomes much easier for any developer to customize each and every other bit of the Android Operating System. The android was usually designed to be a single user operating system (unlike the lollipop and marshmallow where there can be multiple users.) To actually make this simpler, let me put it in this form. Android applications are nothing but Linux processes at the end and that’s how they tend to work. And since I have stated above that every app has its own process, it becomes easier for the kernel to create a separate UID for each process and handle the application files and memory without any extra effort.
There is actually more to this than the Android Operating System basics that I have mentioned above. Android has a core process which is known as the ‘Zygote’ and it excels at what it does. This process actually starts up with the initialization commands when the android boots. I won’t be going into much detail here, but I think Android Operating System basics are actually enough for you to get started with android. To get more information, you can actually visit the source.android.com and developers.android.com which is the official website from google for any and every update on android.
Here are some articles that will help you to get more detail about the Android Operating System so just go through the link.