Android Operating System Architecture in Details
Android OS architecture is a layered stack built on the Linux kernel, with each upper layer relying on services of the layers below it.
High-level layer overview
Application layer: All user-facing apps like Phone, Messages, Settings, and your installed apps live here.
Application framework: Provides high-level Java/Kotlin APIs such as activities, services, content providers, and system managers (ActivityManager, WindowManager, LocationManager, etc.).
Android runtime (ART) and native libraries: Contains the managed runtime (ART) plus core C/C++ libraries like graphics, media, database, and Bionic libc.
Hardware Abstraction Layer (HAL): Defines standard C/C++ interfaces so Android framework can talk to device-specific hardware via vendor implementations.
Linux kernel: The foundation providing process, memory, power, security, and device driver management.
Application layer
At the top, the application layer includes pre-installed system apps (Dialer, Contacts, Camera, Settings) and third‑party apps from Play Store or sideloaded packages. These apps all run in user space and use the same framework APIs, regardless of manufacturer.
Each app runs in its own Linux process with a unique UID, giving process and permission isolation. Inter-app communication happens mainly through intents, content providers, and bound services exposed by the framework.
Application framework
The application framework exposes reusable high-level building blocks implemented mostly in Java. Important components include:
Activity Manager: Manages the app lifecycle and back stack of activities.
Window Manager: Handles windows, views, and their layout on the screen.
Package Manager: Manages app install, update, permissions, and queries for installed packages.
Content Providers: Offer a standard interface for sharing structured data (e.g., contacts, media) between apps.
Notification Manager: Delivers status‑bar and heads‑up notifications from apps to users.
This layer shields app developers from HAL and kernel details by turning low-level capabilities into simple, consistent APIs.
Android Runtime and native libraries
Android Runtime (ART)
ART is the managed runtime used by Android apps and certain system services, executing DEX bytecode produced from Java/Kotlin sources. It supports ahead‑of‑time (AOT) compilation (dex2oat), just‑in‑time (JIT) compilation, and garbage collection to improve performance and memory usage.
ART is modular now, so runtime optimizations and bug fixes can be updated via system updates or Play system updates without a full OS upgrade.
Native C/C++ libraries
Below the framework, Android ships key native libraries used either directly by the framework or via JNI from apps. Examples include:
Bionic libc: Android’s lightweight C library optimized for low memory and mobile constraints.
Media libraries: For audio/video codecs, playback, and recording.
SurfaceFlinger / graphics libraries: For compositing surfaces and interacting with GPU.
SQLite: Embedded relational database engine used by apps for local storage.
These libraries handle performance‑critical work close to the hardware while still being accessible from higher levels.
Hardware Abstraction Layer (HAL)
The HAL defines standard interfaces for hardware features (camera, GPS, audio, sensors, Bluetooth, etc.) so the Android framework can call them without knowing vendor‑specific details.
Vendors implement HAL modules that conform to these interfaces and talk to real hardware via kernel drivers. Since Android 8+, many HALs use the HIDL/AR (AIDL) model and are packaged as separate updatable components to improve modularity.
Linux kernel
At the bottom, Android uses a modified Linux kernel that provides core OS services. Key responsibilities:
Process management: Creating, scheduling, and terminating processes and threads.
Memory management: Allocating and reclaiming RAM, paging, and managing caches.
Device drivers: Managing hardware like display, touch, camera, audio, Bluetooth, Wi‑Fi, USB, and storage.
Security: Process isolation, permissions via UIDs/GIDs, file system security, and often SELinux enforcement.
Power management: Controlling CPU frequency, device sleep states, and waking events to extend battery life.
Android adds its own patches and subsystems on top of standard Linux (like wakelocks and binder IPC support) to better match mobile needs.
How the layers work together (example)
When a user takes a photo in a camera app, the request starts in the app, goes through the framework’s camera APIs, down to the HAL, and finally to kernel drivers to control the sensor; data then flows back up to be processed and shown to the user. This illustrates how each layer has a clear role but they cooperate to deliver a single user‑visible operation.