One of Android’s greatest strengths, and source of occasional frustrations, is its wide variety of software variations. Samsung, Huawei, Sony, and even Google offer their own take on the core Android experience, introducing their own unique features and ideas. This is all made possible thanks to a common base operating system (OS), providing core functionality. All of the Android OS variants that you know and love are based on AOSP – the Android Open Source Project.
The AOSP is an open source operating system development project maintained by Google. Anyone is free to contribute code and fixes to the project repository, but Google oversees its general direction and the bulk of development. The AOSP regularly incorporates the latest bug and security patches for Android. Google also unveils major new features of the OS each year at its I/O developer conference. Android 10 being the latest edition.
As well as being open to contributions, the Android Open Source Project is free to use and alter under an open source license. Smartphone manufacturers, like Samsung and others, are free to tweak the project for their own purposes. However, most phone manufacturers obtain versions of AOSP from a chipset vendor, such as Qualcomm. This is because Android has to be tailored to the low level hardware via drivers, which we’ll get to later on. Either way, Google is happy with this arrangement, as it encourages developers to use Android for a wide range of internet connected gadgets. In return, an array of companies each contribute fixes and improvements to the OS. It’s win-win.
Inside the Android Open Source Project
As I’m sure you can imagine, operating systems are complex beasts. Android is no different. AOSP covers a range of software layers within the operating system, providing access points and tools for hardware and app developers alike.
The “lower level” layers are where device manufacturers code the OS to work with their specific hardware. The Linux Kernel, for example, is the core program which manages the CPU resources, system memory, and networking so that apps and services can run. The Hardware Abstraction Layer (HAL) layer links common app APIs for Bluetooth, sound, etc, with the device’s microphone, speakers, and more.
“Higher level” layers are used by app developers. Native Libraries enable developers to build content with common supported low-level libraries like OpenGL ES, Webkit, and more. Above that, Android Frameworks provides app developers with hook-ins for common OS functions ranging from location data, pushing notifications, and making phone calls. The Android Runtime is the middle man, converting app code into native instructions for the underlying hardware.
Combined all together, the Android Open Source Project stack (pictured above) is a complete solution for Android hardware and software developers.
The AOSP isn’t just an ever growing code base though. Google also provides design and development tools as part of the project, ranging from compatibility documents to best security practices and app design principles. Google also hosts a selection of test suites to help developers ensure their devices implement APIs and features correctly.
AOSP vs Android
The Android Open Source Project is often confused with “stock Android” but that’s an oversimplification.
The AOSP contains everything developers need to build Android but it doesn’t include everything you need for a finished smartphone. First, Google and the AOSP can’t provide kernel device drivers for every hardware configuration out there. By device driver, we mean the firmware required for hardware ranging from a phone processor’s features to the camera. Phone and SoC manufacturers, such as Qualcomm and Samsung, have to incorporate these drivers into their Android build. This is partly why updates take time to trickle down from AOSP to actual devices.
AOSP also doesn’t come with Google’s suite of software applications, such as its Chrome browser, YouTube, and even the Google Play Store. These are licensed separately as Google Mobile Services (GMS).
Any manufacturer that wants to install GMS on top of Android has to obtain a GMS license and a Mobile Application Distribution Agreement (MADA) for their device and then pass several compatibility tests. There’s the Android Compatibility Test Suite (CTS) to validate software and hardware components and APIs. Then the Google Mobile Services Test Suite (GTS) and Vendor Test Suite (VTS) to test multimedia capabilities and OS kernel and HAL capabilities. Another condition for obtaining a GMS license is to pre-load a number of Google’s apps on a new device.
The difference between AOSP and GMS has become an important distinction following the US China trade dispute. The situation prevents Google from licensing GMS to Chinese manufacturers like Huawei. Huawei is building its own Huawei Mobile Services (HMS) equivalent in an attempt to sidestep this issue.
The future of AOSP
The Android Open Source Project continues to be the foundation of Android’s success, thanks to countless hours of developer input from around the world. While Android devices aren’t going anywhere soon, Google is already looking to a future operating system.
Google Fuchsia first popped up on GitHub in August 2016. We still don’t know too much about Fuchsia and if or when it will appear for consumers. It appears to be designed for an even wider range of devices than Android. Fuchsia also features Google’s own non-Linux kernel and supports Google’s Dart scripting language. At the moment, Fuchsia is open source and free software just like Android. Let’s hope any future plans stay that way.
