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. documentation 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. system services and daemons 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. logD, logD, logD logD 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. getSystemService 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. Android Framework 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. 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 runningGo to Device Explorer windowFind and open product folder in device explorerOpen priv-app folder, this is the folder that contains all the privileged apps on a specific Android device. Have a sample Android emulator device running Go to Device Explorer window Device Explorer Device Explorer Find and open product folder in device explorer product product Open priv-app folder, this is the folder that contains all the privileged apps on a specific Android device. priv-app priv-app 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.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Android OS Architecture, Part 2: How the Android System Fits Together

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

The Android OS Architecture: Part 1 — What an Operating System Actually Does

105 Stories To Learn About Ios App Development

10 Things to check on Android code reviews

10 good rules for bad App

The Noonification: Accelerating Android Application Development With the ADB Idea Plugin (10/12/2022)

11 Tips to Save Time on App Development & Launch Processes

The Android OS Architecture: Part 1 — What an Operating System Actually Does

105 Stories To Learn About Ios App Development

10 Things to check on Android code reviews

10 good rules for bad App

The Noonification: Accelerating Android Application Development With the ADB Idea Plugin (10/12/2022)

11 Tips to Save Time on App Development & Launch Processes

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps