What is the difference between Android Open Source Project and Linux based systems?

1. Linux and AOSP Architecture

If you look at the architecture of any embedded Linux system, you will always find the same main components:

1. One or more bootloader(s) to bootstrap that configure the hardware and boot the Linux kernel.
2. The Linux kernel.
3. The root filesystem (rootfs) with the libraries and applications.

Now, if you look at the same diagram for an Android-based system, what would be the differences ?

1. The bootloader is there. Android doesn’t require anything special in the bootloader, although it is common for people to add support to fastboot, a protocol Google created for users and developers to interact with bootloaders on Android-based systems.
2. The Linux kernel or we can call it Androism is a linux Kernel, but with a some changes.
3. The root filesystem is also there. But it is REALLY different! Nothing like a typical root filesystem from Debian or a custom-built rootfs from Buildroot or OpenEmbedded.

As we can see from the image above, Android userspace components are clearly divided in 3 main layers:

1. Native: this is where all native (C/C++) applications and libraries resides. It is called native because it runs outside the ART Virtual Machine. The native layer basically serves the purpose of abstracting Linux kernel interfaces to the framework layer.
2. Framework: this is where all operating system services are implemented (mostly in Java). Access to operating system resources are (remotely) exposed via components called system services, using an IPC/RPC mechanism called Binder. And an API will abstract the access to those system services for the applications.
3. Application: Usually written in Java or Kotlin, they just see the exposed operating system API.

Before studying Android userspace components in details, let’s talk a little bit about the kernel.

Linux kernel

To run an Android-based system, we need a few extra “features” enabled in the Linux kernel. This is some features :

• Binder: this is the IPC (Inter-Process Communication) and RPC (Remote Procedure Call) mechanism used in Android. You could do a rough comparition with DBUS, but DBUS runs in userspace, and Binder is a faster and lighter kernel-based implementation.
• Ashmem: the default shared memory allocator in Android (Google doesn’t like POSIX SHM).
• Low memory killer: a logic built on top of the kernel’s OOM (Out-of-Memory) killer, that in conjunction with a daemon (lmkd), helps to manage the system in low memory situations.

Despite these and a few other main changes in the Linux kernel, Android really differs from an GNU/Linux system in the userspace components and their architecture (the so-called Android platform), and the source-code for the Android platform is provided in a project called AOSP (Android Open Source Project).

AOSP

The AOSP is made of hundreds of repositories (specifically 780 in Android 11), and you can see all of them in https://android.googlesource.com/.

The source code is managed with known tools like repo and git, and it is huge! Android 11 is 100GB of source code plus 115GB after one build. So you really need a lot of disk space to work with the Android source code.

The vast majority of software components are under the permissive Apache and BSD licenses, some software components are under GPL/LGPL licenses, and some Google applications are closed source (e.g. Google Play, Gmail, Google Maps, YouTube, etc). Those applications are available in a package called Google Mobile Services (GMS), and to obtain them, you need to certify the device via Android Compatibility Program (ACP).

When we download AOSP source code, we can see some differences when compared to other approaches for embedded Linux development.

Unlike ready-to-be-used distros (e.g. Debian), you can easily download the full source code and build the distro from scratch (if you want to create a custom Debian system for example, you usually do it from pre-compiled packages).

Comparing to build system approaches (e.g. Buildroot, OpenEmbedded), in Android it seems we have a “big application” downloaded with the repo sync command. Of course this is not true. We have thousands of projects and repositories there, that will compose in the end the operating system images. And the responsibility to put everything together rests with the Android build system…