Before diving into the specific components of the Android operating system that matter in day-to-day development, it helps to step back and look at the Android OS as a whole.
The official Android Open Source Project (AOSP) documentation provides a clear, visual overview of the entire Android operating system, making it a useful reference for understanding how all the pieces fit together.
Layer 1 - Linux Kernel
Let’s start at the lowest level: the Linux kernel. We’ll explore it in more detail in a dedicated article, but in short, it’s the core foundation of the Android OS—and of any Linux-based operating system.
Android is built on top of this Linux foundation, adding behaviors and system-level features that Linux itself does not provide, such as the Android permission model, app notifications, and even the concept of an “app” as we know it.
What Linux does provide are fundamental primitives like processes and the mechanisms for scheduling and managing them—topics we’ll revisit later in more depth.
Layer 2 - System Services and Daemons
The next layer—the pink layer in the diagram above—consists of system services and daemons. These should not be confused with the “System Services” layer that appears higher in the stack; despite the similar naming, they serve different purposes.
The services at this level are low-level components that operate very close to the operating system itself. In general, the lower a layer sits in the stack, the closer it is to the OS.
These components are also referred to as native daemons and libraries. Many of them are familiar from Linux and other Unix-based systems, while others are Android-specific additions built on top of that foundation.
The easiest one to understand is logD, it is just a system service that allows the Android device to log to a certain location and to see the actual device logs. This functionality is provided to all apps running on the device via this logD service.
Layer 3 - Hardware Abstraction Layer (HAL)
The next layer is the Hardware Abstraction Layer (HAL), which you’ve already heard about. It serves as the interface—or communication layer—between everything above the HAL and the layers below it in the stack. Ultimately, the HAL provides high-level APIs to access the device’s hardware, offering a standardized way of interacting with hardware components.
Layer 4 - Android Runtime (ART)
The next layer built on top of the HAL is the Android Runtime (ART). You may have heard of it in your day-to-day work, and we’ll cover it in more detail in subsequent articles. In short, the Android Runtime runs alongside your app, and its purpose is to translate the app’s bytecode instructions (typically written in Kotlin or Java) into actual CPU instructions that the processor can execute directly.
Layer 5 - System Services
Then we have the blue layer known as the System Services. These are quite different from the previously mentioned ones, and you have probably already worked with them as an Android developer. On Android, we have many very specific system services—things like the Location Manager, Notification Manager, and Window Manager. In general, these are the Manager classes you can access via getSystemService in Android Studio.
Layer 6 - Android Framework
At the top of the stack, with the cyan tile is the Android Framework, and here actually a lot of stuff is happening, which becomes interesting, because obviously the higher we get to the top of the stack, the closer it is with our daily work life/real practical work life environment, since as developers, we mostly work on the higher level of course. The Android framework is really just a collection of all kinds of Java and Kotlin APIs, that the Android system (AOSP) is made of.
That includes:
- Android APIs (Public APIs) we can use in code (Activity, Context, Broadcast receiver, Bundle, etc.)
- Hidden/Internal APIs, which are the so-called System APIs, things we can’t directly use in code, but we could use if we were to develop for the AOSP.
So think of the Android Framework as the entire codebase of the Android Open Source Project (AOSP).
Finally, at the top of the Android framework layer, we see several more colorful layers representing different types of apps. All of them have access to the Android framework in some sense, but they differ in which parts of the framework they are allowed to access.
At a glance, we can see that the most privileged apps are device manufacturer apps, which come pre-installed on the Android device. We also have privileged apps, which do not have access to the entire Android framework, but only to a subset of it (Android APIs and system APIs).
Privileged apps also need to be pre-installed, but they do not necessarily come from the device manufacturer. These are simply apps with additional privileges that normal apps do not have
You can also see privileged apps from an Android device on Android Studio by doing the following:
- Have a sample Android emulator device running
- Go to Device Explorer window
- Find and open product folder in device explorer
- Open priv-app folder, this is the folder that contains all the privileged apps on a specific Android device.
The last type of apps that we developers actually build are just Android apps; you can see they just have this yellow square and can only access the Android APIs, and those typical Android-specific classes that we know.
This is basically the overview of the entire Android OS Architecture, and as I said earlier, the lower you get on the stack, the less you’ll interact with parts of the OS in daily work life, and the higher you go on the stack, the more likely you’ll use those in day-to-day work life.