Android architecture: what the system is based on

Many users perceive Android as a single monolithic entity that simply runs on their smartphone. However, behind the familiar interface lies a very complex software structure, consisting of many layers of abstraction. Understanding what Android is actually “made of” is necessary for deep customization of the device, unlocking the bootloader, or even assembling the firmware yourself.

This operating system is based not just on a set of libraries, but a complete one, adapted for mobile devices with limited resources. It is this foundation that provides management of memory, processes, and hardware drivers. But Linux is just the bottom floor of a huge skyscraper, where each subsequent level solves its own unique problems, from accessing hardware to displaying graphics on the screen. Linux kernel, adapted for mobile devices with limited resources. It is this foundation that provides management of memory, processes, and hardware drivers. But Linux is just the bottom floor of a huge skyscraper, where each subsequent level solves its own unique problems, from accessing hardware to displaying graphics on the screen.

Have you ever wondered why Android apps don't run on regular Windows or macOS computers without emulators? The answer lies in the unique runtime and specific libraries that Google has implemented on top of standard Linux. Let's look at this structure layer by layer to understand exactly how your gadget works from the inside.

The foundation of the system: The Linux kernel and its role

The central element of the architecture is the modified Linux kernel. Although Android uses Linux, it is quite different from desktop distributions like Ubuntu or Fedora. Google developers have removed many drivers for desktop-class printers and video cards from the kernel, replacing them with specialized modules for managing batteries, touch screens and radio modules.

This kernel is responsible for the most low-level functions: process scheduling, power management and security. This is where the mechanism Low Memory Killerworks, which forcibly terminates background applications when RAM becomes critically low. Without this mechanism, mobile devices would quickly run out of resources.

Hardware drivers such as display, camera, Wi-Fi and Bluetooth are also at this level. They act as translators between the physical hardware and the rest of the operating system. If the driver is written with errors, this can lead to unstable operation of the entire device, regardless of the quality of the upper layers of the software.

⚠️ Attention: Direct interference with the operation of the kernel (for example, through custom kernels or changing parameters in /proc) without deep knowledge can lead to “bricking” the device or loss of warranty.

The key difference from classic Linux is the absence of standard GNU libraries (glibc). Instead, Android uses its own implementation - Bionic libc. It is optimized for size and speed, which is critical for mobile processors with limited cache.

Hardware abstraction layer (HAL)

Between the kernel and High-level frameworks contain a critical intermediate layer - Hardware Abstraction Layer (HAL). Its main task is to provide a standard interface for the upper levels of the system, hiding the implementation features of drivers from different manufacturers.

Thanks to HAL, application developers do not need to write separate code for a Samsung, Sony or Xiaomi camera. They make calls to a single Android camera API, and the HAL layer translates these requests into specific commands for a specific device driver. This ensures compatibility of thousands of applications with millions of smartphone models.

• 📷 Camera HAL: Controls access to camera modules, image processing and focusing.
• 📶 Audio HAL: Responsible for routing audio streams between the microphone, speaker and applications.
• 📍 Location HAL: Processes data from GPS, GLONASS and cell towers to determine coordinates.
• 🔋 Power HAL: Controls the sleep and wake states of the processor depending on the load.

It is at this level that problems often arise when installing custom firmware. If the firmware developer does not provide the correct HAL libraries (often called "vendor blobs"), functions such as calls or camera operation may simply not start, even if the kernel is loaded successfully.

What are Vendor Blobs?

These are proprietary (closed) libraries from hardware manufacturers (Qualcomm, MediaTek) that are necessary for HAL to work. Without them, the open part of Android will not be able to control a specific processor or modem.

Libraries and Android Runtime

Above the HAL layer are native C/C++ libraries and the application runtime. Early versions of Android used a virtual machine, but starting with version 5.0 Lollipop, it was replaced by a more powerful one. The main difference between ART and its predecessor is the method of code compilation. Dalvik used JIT (Just-In-Time) compilation, translating bytecode into machine instructions while the application was running, which wasted CPU and battery resources. ART uses AOT (Ahead-Of-Time) compilation: application installation is accompanied by complete compilation of the code into machine instructions. Dalvik, but starting with version 5.0 Lollipop, it was replaced by a more productive one Android Runtime (ART).

The main difference between ART and its predecessor is the method of code compilation. Dalvik used JIT (Just-In-Time) compilation, translating bytecode into machine instructions while the application was running, which wasted CPU and battery resources. ART uses AOT (Ahead-Of-Time) compilation: installation of the application is accompanied by complete compilation of the code into machine instructions.

This makes applications launch much faster and reduces the CPU load during use, although it increases installation time and memory footprint. For developers, this means that they write code in Java or Kotlin, which compiles into bytecode .dexreadable by the Android runtime.

Component	Function	Implementation language
Surface Manager	Management access to the display subsystem and window compositing	C++
Media Framework	Support for playback and recording of audio/video formats	C++
SQLite	Lightweight relational database for storing application data	C
Webkit	Engine for displaying web content (the basis for WebView)	C++
OpenGL ES	Hardware acceleration for 2D and 3D graphics	C

These libraries are available to developers through the app framework, but some of them, such as libc or libcrypto, are used by system processes to provide basic functionality and data encryption.

Application framework and system services

The tip of the iceberg, with which the user directly interacts, is the application framework level. There are System Server here are many managers who coordinate the work of the entire system. It is this layer that provides the API that all applications from Google Play use.

This section contains entities such as Activity Manager, which manages the life cycle of applications, and Window Manager, which is responsible for drawing windows on the screen. When you minimize an application or receive a notification, behind these actions there are complex interactions between framework components.

• 📦 Package Manager: Monitors the installation, update and removal of applications, managing their access rights.
• 🔔 Notification Manager: Processes a queue of notifications and controls their display in the status bar.
• 📞 Telephony Manager: Provides access to functions calls and cellular network status.
• 📍 Location Manager: Manages geolocation requests from various services.

Developers can access these services through Java/Kotlin classes. For example, to access contacts, an application requests permission from ContentResolverwhich checks permissions and returns data from the system database.

It is important to note that smartphone manufacturers often modify this level by adding their own shells (MIUI, OneUI, ColorOS). They can change the logic of managers, add new system applications, or change the behavior of notifications, which sometimes leads to conflicts with standard Android behavior.

Security and permission model

Because Android is based on Linux, it inherits the OS's powerful security model based on user and group rights. Each installed application in Android runs as a separate Linux user with a unique UID (User ID).

This means that by default the application does not have access to other application data or system files. This isolation, called a sandbox, prevents the spread of malicious code and data theft. If one application is compromised, the attacker will not be able to automatically gain access to the banking application.

To access protected resources (camera, contacts, microphone), the application must explicitly ask the user for permission. This check occurs at the application framework level. In modern versions of Android (from 10 and above), access to a location or files can only be granted “while using the application.”

⚠️ Attention: Granting permissions to system applications or launchers via ADB (commands pm grant) may disrupt the stability of the interface. Do this only if you understand the consequences.

In addition, the system implements a mechanism Verified Boot. Every time the device boots, the digital signature of all system sections is checked, starting from the bootloader and ending with the system image. If the integrity is violated (for example, when trying to implement root access), the system may not boot or go into a limited operating mode.

Differences from classic Linux distributions

You can often hear the question: “Can Android be considered just another Linux distribution? Technically the kernel is, but the user space is radically different. On regular Linux, you use GNU Coreutils, the systemd init system, and the X11 or Wayland graphics subsystem.

Android doesn't have any of these components in a traditional form. It uses its own initialization system init, which reads scripts from /init.rc. The graphics subsystem is based on SurfaceFlinger, not the X server. User utilities have been replaced by a toolbox, specially trimmed down to save space.

There is also no support for standard package managers like apt or yum. The software is installed through the app store, which unpacks APK files into isolated directories. This makes Android a more closed and controlled environment compared to desktop Linux.

However, thanks to the Termux project and the presence of the Linux kernel, modern smartphones can run full-fledged Linux distributions in emulation mode or via chroot, gaining access to real developer tools.

FAQ: Frequently Asked Questions

Is it possible to install apps for regular Linux on Android?

Directly - no, due to differences in libraries (Bionic vs. glibc) and architecture. However, you can use emulators (Termux, UserLAnd) or containers that create a compatible environment for running console utilities and even graphical Linux applications.

Why does Android require so much RAM?

This has to do with the operation of the ART virtual machine and the way the system manages processes. Unlike iOS, where apps freeze quickly, Android apps often remain in memory in the background for quick switching. The Low Memory Killer mechanism monitors this, but the memory reserve is necessary for smoothness.

What is the difference between root access and superuser rights in Linux?

Conceptually there is no difference - this is full access to the system. But on Android, getting root access requires unlocking the bootloader and modifying the system partition (or using Magisk), which breaks the Verified Boot trust chain and can lead to failure of banking applications.

Why did Google replace Dalvik with ART?

The replacement was made for the sake of performance. ART compiles application code upon installation, which eliminates startup delays and reduces CPU power consumption while running, although it increases first-time installation time and space footprint.

Is it possible to change the Android kernel to a different one?

Theoretically, yes, as long as you have an unlocked bootloader and the kernel source code for your device (which is required under the GPL). In practice, this is done by developers of custom kernels (Kernels), who optimize processor frequencies or add overclocking support.