An overview of the Android system

Android, as with every other operating system, has a layer-based structure. The next image shows a properly abstracted overview of the whole system architecture:

We can divide the system into the following main layers:

• Linux kernel
• Hardware abstraction layer
• Core libraries and runtime environment
• Application framework
• Binder IPC
• Applications

The software layer closest to the hardware architecture is the Linux kernel. This layer is in charge of communicating with the hardware components and provides an easy-to-use interface for the layer above.

Moving up on the architecture path, we have Android runtime and core libraries. This layer provides the basics tools for the application framework. The application framework is a collection of ready-to-use components that the system provides to the Applications layer via the Android SDK. The top layer contains all those applications we use everyday—games, productivity apps, multimedia, and so on.

Linux kernel

Android is based on the Linux kernel, but it's not a classic Linux-based desktop system: it's not Ubuntu. However, Android architecture designers and developers rely on the Linux kernel, because it's open source, it's extensively tested worldwide, and it can be easily tailored to fit Android-specific hardware needs, on any kind of device.

From a very pragmatic point of view, choosing to base the system on an open source heart reinforced the Android philosophy of being an open system, supported by its community and trusted by enterprise companies, thanks to its transparency. Besides, this approach saved a lot of development time—they didn't have to start from scratch and they could focus on the rest of the architecture, taking advantage of a popular and well-documented core.

The vanilla Linux kernel needed some love to properly fit all the Android requirements. Most of the contributions by Google were focused on:

• Fixing bugs
• Enabling new hardware
• Improving power management
• Improving error reporting
• Improving performance
• Improving security

From a hardware point of view, the Android team made a great effort to add new goodies to the Linux kernel. Lots of fixes and hacks were released to improve Bluetooth support and management, lots of General Purpose Input/Output (GPIO) drivers were added, ARM compatibility was enhanced, as ARM was the primary Android-supported architecture and also MMC management received lots of contributions. The new ADB gadget driver was added to help developers to communicate via USB with external devices.

From a memory point of view, the Android team introduced PMEM, the process memory allocator. This gave the ability to manage large physically contiguous memory regions between user space and kernel space. Working in a specific low-resource hardware domain, the Android team released Ashmem, Android Shared Memory, which targeted low-memory devices and provided an easy-to-use file-based API to manage shared memory, especially under memory pressure.

From a power management point of view, the Android team introduced an improved suspend system, wakelocks, and Android Alarm Timers, the kernel implementation to support Android Alarm Manager.

The other interesting contributions were the kernel support for Android logcat command, that provides logs of system messages, application debug messages, and exceptions, and Android Binder, an Android-specific interprocess communication system, used for remote method invocation too.

Hardware abstraction layer – HAL

To overcome the increasing hardware fragmentation, Android engineers created an abstraction layer that allows the system to interact with the hardware just being aware of a specific intercommunication interface. The system completely ignores the low-level implementation of hardware and drivers. This approach enforces the idea of developing software against an interface instead of against an implementation. With this approach, the Android system does not know and does not need to know how hardware is accessed or managed.

As a mid-level layer between the hardware and the system, Android HAL is commonly developed using native technology—C/C++ and shared libraries. There is no constraint from Google about how we need to implement our HAL and our device drivers: it's up to us to design it as we think best for our scenario. There is only one simple rule:

Our implementation must provide the same interface that the system is expecting.

Libraries and the application framework

Going up on the architecture ladder, we find the two most important software layers. The Android application framework and Android system libraries are the middleware between the bare hardware, managed by the Linux kernel, and all those fancy, shiny apps we have on our smartphones.

Libraries

Android system libraries are a set of libraries, specifically created to work on Android, to allow and help with system components and app development. The most important are:

• SQLite: SQLite is the entry point to the SQL world. It's a tiny SQL implementation for embedded systems and it provides a standard way to access data published by content providers or SQL DB created by the user.
• SSL: SSL provides the standard security environment for network communication.
• OpenGL: OpenGL libraries are the link between the Java (and C/C++ JNI) world and the OpenGL/ES 3D graphics rendering API.
• SGL: SGL provides a way to access 2D rendering engine.
• Media framework: Media framework provides codecs for rendering, recording, and playback for the most common media formats.
• WebKit: WebKit is the popular HTML rendering engine.
• libc: The libc library is a BSD-derived implementation of the standard C library, specifically tuned to best perform on embedded Linux-based devices.
• Surface manager: Surface manager manages access to the display subsystem.

The application framework

This is the core of the Android software ecosystem. It provides a plethora of managers that facilitate the most common tasks of Android developers and the Android system itself. The most important components of the Application Framework are:

• Activity manager: This provides the navigation backstack and manages the Android activity lifecycle
• Resource manager: This provides access to noncode resources contained in the apps: graphics, localized string, styles, and colors
• Location manager: This is in charge of providing the most accurate position information, using data collected by the GPS sensor, from cell towers and Wi-Fi networks nearby
• Notification manager: This enables apps to display notification alerts in the status bar, according to Google Design Guidelines, to provide a common and familiar user experience
• Content providers: This provides a common approach to share data between different apps, for instance, accessing contacts data or sharing a common data set between two apps
• Views and widgets: These comprise the UI core of the Android experience. Buttons, text fields, and layouts are the building blocks of every Android system component and user app

Everything on Android is achieved using the official Android SDK that provides a consistent and documented way to use all these system managers, views, and logic components to let you create the next big hit of the Google Play Store.

Binder IPC

From an Application Framework point of view, the Binder Inter-Process Communication (IPC) is a hidden layer. It takes care of creating a transparent communication channel between the high-level Android API, accessible via the Android SDK, and the actual Android system.

The application layer

All the applications created by third-party entities, such as smartphone manufacturers or Android programmers will be installed on the application layer.

Usually, this relies on a read/write area of the handset solid memory, but for software provided by manufacturers, typically, it uses a read-only memory area to be sure that these applications will always be installed no matter what. Apps such as Google Maps, YouTube, Samsung TouchWiz Nature, and HTC Sense are examples of apps in this very group: they are shipped with the device's operating system, they are installed on a read-only memory area of the device, and they are meant to be uninstallable as a core component of the system.

As we will see, this is not 100% true—once you have the proper skill set, you will be able to manipulate the whole system. In the following chapters, you will acquire these skills and you will learn how to heavily modify an already existing Android version and get rid of those apps, if necessary.