Table of Contents

1. Early Days of Android
2. Android Stack
3. Linux Kernel
4. Secure Element
5. Hardware abstraction layer
6. Native Libraries
7. Runtime
8. Framework
9. Apps
10. References
11. Contributions

Understanding the internals of Android Stack Architecture and how it relates to Linux. This blog post aims to be the starting point for developers to get familiar and have an overview of core components in the Android Stack Architecture.

Early Days of Android

Founded in 2003, Android Inc, in the early days began as an operating system for Digital Cameras.

Due to the low market for Digital Cameras, the Android Inc teams' intentions slowly diverted to Mobile Devices. Becoming the rivals of then Symbian and Windows Mobile.

Acquired by Google in 2005, the development team worked on an Operating System based on Linux Kernel in shadows until the unveil of Open Handset Alliance in 2007.

Android Stack

By Google, Android is described officially as an open-source, Linux-based software stack created for a wide array of devices and form factors.

The graphical user interface environment, middlewares, libraries, APIs... sitting on top of Linux Kernel and shell binaries are Software Stack Layers that make the bulk of Android and which makes it much more than a variation of Linux system.

Linux Kernel

Android's Kernel is based on the Long Term Support (LTS) branches of the Linux Kernel.

The kernel provides drivers for filesystem access, process management, hardware, networking. The Android Kernel differs from vanilla Linux Kernel due to the differences called as *Androidisms*

Some of the notable Androidisms added to Kernel are IPC Binder, Wavelocks, Low-Memory Killer, Dalvik, and Android Runtime, Anonymous Shared Memory (ashmem), Alarm, paranoid network, RAM console, Physical memory (pmem), Sync driver, Timed Output and GPIO, memory and logging enhancements.

Android utilizes many unused/less-popular features in desktop distributions of Linux such as control groups, Low Memory Killer Daemon, Security-Enhanced Linux (SELinux), and open source projects like a racoon for VPN, mdns for network service discovery and many more.

Secure Element

To provide better security, some devices have an embedded Secure Element (SE), which is dedicated, separate tamper-resistant hardware to store cryptographic data.

Hardware abstraction layer

Android runs on TV, Mobile, Refrigerator and almost everywhere that the underlying hardware may greatly differ in its' scope and support.

To solve this the Android stack typically relies on shared libraries provided by manufacturers to interact with hardware.

Android relies on what can be considered a Hardware Abstraction Layer (HAL), although the interface, behavior, and function of abstracted hardware components differ greatly from type to type.

The idea of GPS, sensor, TV, camera, audio, input media components and other components behavior is defined by HAL and how it should behave in Android. The vendors are still not allowed to make unnecessary modifications so as to not fail the Compatibility Test Suite, Vendor Test Suite.

Native Libraries

The native libraries layer is responsible for providing support for the core features. The WebKit Web rendering engine, Audio Manager, LIBC, Secure Sockets Layer (SSL), FreeType for rendering fonts, Media, OpenGL ES graphics API, SQLite database, Surface Manager.

Runtime

Before Android 4.4, each Android app would run on its own virtual machine, which is called "Dalvik" which got superseded by the Android RunTime (ART). In Android 4.4, along with Dalvik, Google experimentally introduced a new Android Runtime called "ART" which still today remains the standard.

ART introduces ahead-of-time (AOT) compilation, which can improve app performance.

App runs and launches faster on ART than Dalvik because DEX bytecode gets translated into machine code during installation which means no compilation during runtime and thus seemingly faster!

Because Dalvik requires extra memory for Just-in-time code cache, an app occupies a smaller memory footprint when it runs on ART."

Framework

The Android application creation process is provided by Application frameworks/libraries which allows developers to use the higher-level Kotlin or Java language, rather than low-level C/C++.

The framework includes the basic blocks for building Android applications such as Content Provider, Activity Manager, Location Manager, View System, Package Manager, Notification Manager, Resource Manager, Telephony Manager, Window Manager.

Android frameworks are divided into separate namespaces using the Java package naming and according to their functionality.

Packages in the android.* namespace is available for use by developers.

Packages in com.android.* are internal.

Android also supports most of the standard Java runtime packages in the java.* namespace.

Apps

The topmost layer in the Android Stack is the Applications layer which can be categorized into System apps and user-installed apps.

System apps cannot be uninstalled or changed by users and are read-only in production devices.

System apps are included in the OS image, mounted as /system

User-installed apps can be uninstalled at will. Each application lives in a dedicated security sandbox and cannot affect other applications or access their data.

User-installed apps are installed on a dedicated read-write partition, mounted as /data that host user data.

References

https://developer.android.com/guide/platform

https://source.android.com/

https://en.wikipedia.org/wiki/Android_(operating_system)

https://software.intel.com/content/www/us/en/develop/blogs/art-vs-dalvik-introducing-the-new-android-x86-runtime.html

http://newandroidbook.com/

Android Security Internals: An In-Depth Guide to Android's Security Architecture

Embedded Android: Porting, Extending, and Customizing

Relevant Video on "Awesome Dev Notes" YouTube

Contributions

Contributions and Pull requests are welcomed at https://github.com/androiddevnotes repositories!

🐣

Authors

---

Android Dev Notes

github.com/androiddevnotes

Open-source contributor