Android (operating system) - Android System Architecture

Understanding the Android Software Stack Introduction Android is built as a layered software system running on top of the Linux kernel. Understanding how these layers fit together—from the kernel at the bottom to your applications at the top—is fundamental to comprehending how Android operates. This guide explores the architecture that makes Android work, including the runtime environments that execute code, the libraries that provide essential functionality, and the kernel modifications that tailor Linux for mobile devices. The Software Stack: Layers Above the Kernel Android's architecture is organized in layers. Above the Linux kernel sits a rich ecosystem of middleware, C libraries, and Java-compatible APIs that together form the application framework. Each layer builds upon the ones below it, creating a complete platform where applications can run efficiently on diverse hardware. The key layers include: Linux Kernel: The core that manages hardware and processes Native Services and Libraries: C/C++ libraries including Bionic Android Runtime: The environment that executes applications Application Framework: APIs and services for app developers Applications: User-facing apps built by developers This layered approach provides abstraction—apps don't need to worry about the specific hardware they're running on. Instead, they interact with standardized APIs provided by the framework layers below. Runtime Environments: How Android Executes Code From Dalvik to ART Android must convert application code into something the device's processor can execute. This conversion process has evolved significantly. Dalvik was Android's original runtime environment. It used just-in-time (JIT) compilation, a technique where the system monitors which code paths are used frequently (called "traces") and compiles only those parts to machine code while the app is running. This approach saved memory and startup time, which were critical for early mobile devices. However, this compilation happening during app execution could cause unpredictable slowdowns. Android Runtime (ART) became the default runtime starting with Android 5.0, replacing Dalvik entirely. ART uses ahead-of-time (AOT) compilation, which converts all of the app's bytecode to native machine code during installation, before the user ever runs the app. This means: Apps start up faster (no compilation needed at runtime) Apps run more smoothly (no mid-execution compilation pauses) However, installation takes longer and requires more storage space This shift represents a fundamental trade-off: Android chose to spend resources up-front during installation to provide better user experience during actual app use. Standard Libraries: The Foundation of Functionality Java Libraries Android's Java library (the set of standard classes available to Java developers) was originally based on Apache Harmony, an open-source implementation of Java. In 2015, Android switched to using OpenJDK, the open-source reference implementation of Java maintained by Oracle and the community. This move brought Android closer to standard Java while ensuring long-term compatibility and community support. Bionic: Android's Custom C Library Most Linux distributions use the GNU C Library (glibc), which is the standard C library for Linux. Android, however, uses Bionic, a BSD-licensed C library developed specifically for Android. Why create a custom C library? Bionic was designed from the ground up for low-memory devices, making it much smaller and faster than glibc while still providing the essential C library functionality that native code needs. This decision reflected Android's origins on memory-constrained phones, where every megabyte counted. The existence of Bionic (rather than using glibc) is actually one reason some people debate whether Android should technically be called a "Linux distribution." The Linux Foundation and many experts do classify Android as a Linux distribution because it uses the Linux kernel and most Linux userspace tools, even though Bionic replaces the traditional C library. Native Development Support For developers who need maximum performance or want to write in C or C++ rather than Java, Android provides the Android Native Development Kit (NDK). The NDK enables you to: Write entire applications in C or C++ Write performance-critical components while keeping the rest of your app in Java Call native libraries written in C or C++ The NDK uses JNI (Java Native Interface) shims to allow Java code and native code to communicate with each other. A shim is essentially a adapter layer that translates calls from one language to another. The Linux Kernel: Android's Foundation Kernel Versions and Evolution <extrainfo> As of 2024, Android 14 devices use Linux kernel versions 6.1 or 5.15 for new features, though devices launching with older kernels may use versions 5.4, 4.14, or 4.9. The specific kernel version varies based on device manufacturer and the processor architecture used. </extrainfo> Android-Specific Kernel Modifications Android modifies the standard Linux kernel with several Android-specific additions: Device trees: Configuration data that describes the device's hardware Ashmem (Anonymous Shared Memory): A memory-sharing mechanism optimized for low-memory conditions ION: A memory allocator designed for multimedia operations Custom out-of-memory handling: Special logic for when the system is running low on memory These modifications tune Linux specifically for the constraints and requirements of mobile devices. The Mainlining Project Starting in December 2011, Google launched the Android Mainlining Project, an effort to upstream Android-specific drivers and features back into the official Linux kernel. Rather than maintaining a completely separate version of Linux, this project aims to integrate Android's innovations into the main Linux codebase. This began with Linux 3.3 and continues to this day. Mainlining benefits everyone: it reduces fragmentation, ensures better compatibility, and allows Android to benefit from improvements made by the broader Linux community. Hardware Support Processor Architectures Android supports multiple processor architectures, which means the same app can run on devices with different types of processors: Primary support: 64-bit ARM (ARMv8-A) and 32-bit ARM (ARMv7-A). These are the standard architectures in most Android phones and tablets. Official support: x86-64 and 32-bit x86, used in some tablets and specialized devices. Unofficial ports: Exist for RISC-V and earlier MIPS architecture, though these are not officially supported by Google. The prevalence of ARM is due to its efficiency in battery consumption, making it ideal for mobile devices. Graphics Rendering Android supports: All versions of OpenGL ES, the mobile variant of OpenGL for rendering graphics Vulkan, a modern graphics API that provides lower-level hardware access and better performance. Vulkan 1.1 is available on some devices. These APIs allow developers to create visually rich applications with hardware-accelerated graphics. <extrainfo> Optional Hardware Features Depending on the device, Android may support various sensors including cameras, GPS for location, motion sensors (accelerometers and gyroscopes), environmental sensors (barometers, magnetometers, thermometers), proximity sensors, pressure sensors, and touchscreens. Apps can request access to these features, and the system will deny the request on devices that don't have the hardware. </extrainfo> Storage Architecture: Local and External Understanding Android's storage system is important because it affects how your apps save data and access files. Portable vs. Adoptable Storage Portable storage (the default mode) treats an SD card as removable media, similar to how a USB drive works on a computer. The card can be removed and used with other devices. Adoptable storage, introduced in Android 6.0, is a different approach: the system can merge an SD card with internal storage, making it a seamless extension of the device's main storage. However, this comes with a trade-off—an adoptable SD card becomes formatted in a way that makes it unavailable to other devices unless you reformat it back to standard portable storage. Storage Access Framework The Storage Access Framework (SAF), introduced in Android 4.4, provides a unified way for apps to access files across the device. Rather than different apps using different mechanisms to access files, SAF gives them a standard set of APIs. When an app needs to open or save a file, SAF handles presenting the appropriate file picker interface to the user. Scoped Storage: Modern Access Control Starting with Android 11, Android introduced scoped storage, a significant shift in how apps access files. Rather than having broad permission to access any file on the device (if the user grants permission), apps now have automatic access only to: Specific media directories (Photos, Documents, Downloads, etc.) for files the app created App-specific folders where the app can store its own private data Other locations only with explicit user permission per file Scoped storage represents a privacy improvement, preventing apps from broadly scanning all files without user awareness. This is an important restriction you must understand when developing Android apps. Memory Management: Keeping Android Responsive Intelligent Process Suspension Android keeps devices responsive and battery-efficient through automatic process management. When you close an app or switch away from it, Android doesn't immediately destroy the process. Instead, it suspends inactive apps, putting them into a paused state where they consume minimal CPU and battery resources. When you return to the app, it wakes back up almost instantly. Automatic Cleanup Under Memory Pressure When the device starts running low on available memory, Android automatically closes the longest-inactive processes to free up memory. This happens silently in the background—users don't see notifications, and closed apps don't get to perform cleanup operations. This behavior is fundamental to how Android handles memory constraints. <extrainfo> A Note on Task Killers You might encounter third-party "task killer" apps that claim to improve performance by automatically closing apps. In practice, these are generally counterproductive. Since Android already closes inactive apps automatically, task killers either do the same job (wasting battery by constantly checking which apps to kill) or they kill active apps the user actually wants to use. They may even degrade overall performance. </extrainfo>