Is Android Linux or Not? Clearing Up All Your Confusion in One Article

0.1 Linux Is Just a Kernel#

Under the strictest definition, Linux is not a complete operating system at all; it is merely a kernel

In 1991, when Finnish university student Linus Torvalds wrote the first line of code, what he wrote was just a kernel program

What does a kernel do? It manages CPU scheduling, memory allocation, network communication and drives the underlying hardware (for example, letting the motherboard recognise your network card and keyboard). It is merely an engine — you can’t drive an engine down the highway on its own

Android does use the Linux kernel, so at this extremely narrow level, you can say Android includes Linux

0.2 What Is GNU/Linux#

Since Linux is just a kernel, what exactly are the Arch, Debian, CentOS and even domestic Deepin systems we normally use — complete systems with a desktop, a command line and the ability to install software?

This brings us to Richard Stallman and the GNU Project he launched In 1983, Stallman decided to build a completely free, open-source operating system. His team spent years developing almost all the upper-layer components an operating system needs:

• The C standard library glibc: the foundation every piece of software runs on
• Compiler: the machine that turns code into executable programs
• Command-line toolset: such as the ls, cd, cp and rm you type in
• Shell environment: such as the famous Bash

By the early 1990s, the GNU team had everything ready: a beautifully built chassis, steering wheel and body — all that was missing was a good engine (their own kernel, Hurd, had stalled). On the other side, Linus had just built an excellent engine (the Linux kernel), but had no body

So the two hit it off immediately. Linux kernel + GNU toolchain = a complete, usable operating system

Therefore, the traditional Linux distributions we use today on servers and personal computers should, academically speaking, most accurately be called GNU/Linux. What we usually mean by “I use a Linux system” is actually short for “a GNU/Linux system”

0.3 What Is Android#

With the history above understood, the essence of Android becomes very clear

When Google decided to develop a smartphone operating system, it took a liking to this super engine, Linux — but Google did not want the car body GNU had built

To adapt to the characteristics of mobile devices, and to avoid the strict open-source licences behind GNU (which will be covered in detail in later sections), Google took the Linux engine out and built an entirely new sports car around it

1.1 GPL#

In traditional GNU/Linux systems (such as Ubuntu), from the Linux kernel up to the upper-layer GNU core components (the C standard library, command-line tools, etc.), the vast majority use the GPL

The original intent of the GPL is extremely noble and pure: defend the absolute freedom of software. It stipulates: you may use my code for free and modify it as you like, but any derivative software that uses GPL code or links against GPL libraries must also open-source all of its source code under the GPL

From our perspective, this is called the baton of freedom. In the eyes of a commercial company’s legal department, it is called a viral licence

What does this mean for phone hardware manufacturers? Suppose Qualcomm spent a billion USD developing a GPU with top-tier graphics performance, or Samsung developed an extremely advanced camera algorithm. To make this hardware work on a phone, they must write hardware drivers

If Android had copied the GNU/Linux architecture unchanged, Qualcomm and Samsung would inevitably have to call the underlying code libraries protected by the GPL when writing drivers. Once they did (even if all they did was link a .so dynamic library), under the GPL’s infectiousness, Qualcomm and Samsung would have to publish the source code of the GPU and camera drivers they spent enormous sums developing

This amounts to handing their trade secrets to competitors for free. If Google had said to hardware manufacturers back then, “Use my Android system; the price is making all your core technology code public”, then without a doubt, Android would have died at birth, and any OEM would have left it standing outside the door

1.2 Apache#

Google isn’t stupid; it knew clearly that the best way to build a phone operating system that monopolises the globe is to build a huge commercial alliance

To attract giants like Samsung, HTC, Qualcomm and MediaTek, Google had to give them a reassurance: use my system, and you’re allowed to keep your code closed

To deliver on that promise, Google made an extremely major architectural decision: ban the GPL from user space and turn fully right toward Apache 2.0

Apache 2.0 (and similar BSD and MIT licences) are called extremely business-friendly licences. You can use my code for free, mess with it however you like, and you can also keep it closed source and use it to make money

This suited hardware manufacturers and closed-source commercial software developers perfectly

1.3 Architectural Guiding Principles#

But the reality is that the Linux kernel itself is GPL. How to do?

Fortunately, Linus made an extremely important declaration back then: normal system calls (that is, upper-layer software calling into the underlying kernel to get things done) do not constitute derivative works and are not subject to GPL infection

Google sharply grabbed this lifeline and established the highest principle of Android’s architectural design: isolate the GPL:

1. Lock the GPL strictly inside the kernel layer: the unmodifiable Linux kernel at the bottom — Google accepted it, and it still complies with the GPL
2. Fully de-GNU the upper layers: nothing above the kernel is allowed to show any trace of the GPL. Google went to work ruthlessly and killed off all those core low-level libraries in traditional GNU/Linux that carried the risk of GPL infection (such as glibc and all the core command tools), and spent its own money rewriting a set of replacements
3. Move drivers upward: traditional Linux drivers live inside the kernel. To keep hardware vendors’ drivers from being infected by the kernel’s GPL, Google forcibly inserted a hardware abstraction layer, HAL, in the middle of the architecture, so vendors could move the core driver code out of the kernel and run it closed-source in user space

2.1 Starting In-House Development#

• libC is the most important cornerstone of any operating system built on the Linux kernel. It is the only bridge through which all upper-layer software (whether native programs written in C++ or the Java virtual machine) communicates with the underlying Linux kernel

• Traditional GNU/Linux: uses the famous glibc. It is extremely large, comprehensive in features, fully POSIX-compliant, and very fast. But it has two weaknesses: first, it is under the GPL. Second, it takes up too much memory — for the pitiful RAM of early-generation 2008 smartphones, it was too heavy

So Google abandoned glibc and, based on the BSD licence, rewrote a lightweight C standard library itself, named Bionic libc

• Small: its size is only a fraction of glibc’s
• Fast: instruction-set optimisations specifically for the low frequency and low power consumption of mobile ARM processors

So what was the cost? It cut a large number of POSIX standard features that phones don’t use. This is also why many traditional Linux C/C++ programs cannot be compiled and run directly on Android

2.3 Killing Off the Command-Line Toolset#

In traditional Linux, the ls, grep and so on you type all come from the GNU Coreutils package

To avoid suspicion, early Android wrote its own minimal command set called Toolbox, also based on BSD. Later, as the system developed, Toolbox gradually became insufficient, so starting from Android 6.0, Google switched entirely to the Toybox project initiated by Rob Landley

Toybox is an extremely magical project: it packs hundreds of common Linux commands into one small binary, and it uses the BSD/0-clause licence (extremely permissive — almost equivalent to waiving copyright claims) So the ls you type on an Android phone and the ls you type in Arch, although they look the same, are completely different things underneath

2.3 Killing Off the Compiler#

Initially, Android, like all Linux, used GNU’s GCC as the official compiler for C/C++ code. But GCC is also a disaster zone for the GPL

As the Apple-led open-source compiler architecture LLVM/Clang (under the permissive Apache/UIUC licence) matured, Google followed without hesitation. Starting with Android NDK r11 it gradually recommended Clang, and by r18 Google simply deleted GCC entirely. Today’s Android system and its native ecosystem are now completely compiled with LLVM/Clang

3.1 Monolithic Kernel#

Linux is a Monolithic Kernel operating system. This means that in traditional GNU/Linux, hardware drivers are stuffed directly into Linux kernel space and run there

This creates a legal time bomb:

1. The Linux kernel is under GPLv2
2. For your driver code to run inside the kernel, it must call the various APIs the kernel provides
3. Under the GPL, this constitutes a derivative work
4. You must open-source it

This is absolutely unacceptable to major hardware vendors. If they don’t use Android, they’d have to write an operating system from scratch. If they do use Android, their trade secrets would be forced into the open. The situation once fell into a dead end

3.2 HAL#

To break out of this deadlock, Google’s architects forcibly inserted a brand-new concept between the Linux kernel and the upper Android framework: HAL Hardware Abstraction Layer

Since the GPL only constrains kernel space, we’ll move the core logic of the drivers out of kernel space and into user space, where the GPL doesn’t apply

The specific approach is as follows:

1. Hardware vendors write only an extremely simple placeholder driver, a Stub, in the Linux kernel. This driver only handles the most basic hardware read/write instructions, and is open-sourced directly
2. Hardware vendors write the real control logic, image-processing algorithms and complex scheduling mechanisms as a closed-source dynamic link library (a .so file), placed in the HAL layer in user space. This part of the code is protected by Apache 2.0 and is fully closed-source
3. When you open the phone camera, the upper Android application calls the API -> the system service finds the closed-source .so library in the HAL layer -> the .so library then sends simple instructions to the open-source stub in the underlying kernel

Through this magnificent architectural magic trick, Android perfectly protected the core interests of all the hardware giants This is also why, under /vendor/lib/hw/ in an Android phone’s file system, you can see a pile of .so files provided by Qualcomm or MediaTek whose source code you simply cannot see

3.3 Project Treble#

In the early days, the HAL layer code was bound together with the Android system framework. This meant that every time Google released a new version, vendors had to modify their HAL code again, which led to the extremely notorious upgrade fragmentation of Android phones (vendors couldn’t be bothered to change it, so your phone stayed forever on an old version)

To solve this problem, Google introduced Project Treble in Android 8.0 They designed an interface definition language called HIDL/AIDL. It amounts to creating a standard socket between the HAL layer and the Android framework

From then on, hardware vendors’ closed-source drivers became completely independent modules (the Vendor partition). When Google upgrades the Android system (the System partition), it only needs to unplug the old one and plug in the new one; the underlying closed-source drivers don’t need a single change to be compatible with the new system

4.1 Abandoning X11 and Wayland#

Traditional Linux desktop systems long used X11, and later gradually transitioned to Wayland. X11’s design originated in the 1980s; it supports network transparency (you can project a software GUI from a remote server onto a local computer for display). This design is very suitable for research and server environments, but it is extremely bloated, with huge overhead passed through layer after layer — far too much for a phone screen

Google decisively abandoned X11 and Wayland, and tailor-made a display framework centred on hardware rendering specifically for mobile devices. Its absolutely core component is called SurfaceFlinger

Its working principle is extremely simple and efficient: in Android, every app (even every button, every pop-up) is abstracted at the bottom into a layer. The app process is only responsible for drawing its own layer (through OpenGL ES or Vulkan). Then all the layers are handed to SurfaceFlinger

SurfaceFlinger is a compositor: it uses the phone’s GPU and a dedicated hardware composer (HWC, Hardware Composer) to overlay these layers like a double cheeseburger (which is very tasty) in an extremely short time (say 16.6 milliseconds), arrange them by Z-order, and push them to the screen in one go — no concept of a mouse pointer, no complex window dragging and overlapping logic (in the early days), everything giving way to full-screen touch and lightning-fast rendering

4.2 The Audio Subsystem#

Traditional GNU/Linux uses the ALSA driver at the bottom, and at the top usually uses PulseAudio or the newer PipeWire for audio mixing and routing

At the bottom, Android still keeps the ALSA driver (because it’s part of the Linux kernel), but Google likewise overturned the entire upper layer and wrote its own audio policy server called AudioFlinger. It is optimised specifically for the complex scenarios of phones: for example, when you’re listening to music (media volume) and a call suddenly comes in (ringtone volume), it can implement extremely precise audio focus preemption, mixing, hardware decode offload and ultra-low-latency audio processing

5.1 Abandoning Traditional System V IPC#

Traditional Linux provides a rich set of IPC mechanisms: pipes, signals, message queues, shared memory, sockets and so on (collectively System V IPC or POSIX IPC)

• Why doesn’t Android like to use them?
  • Pipes and message queues: the data must be copied from process A to the kernel, then from the kernel to process B — two copies, performance too poor
  • Shared memory: extremely high performance (zero copies), but extremely complex to control, with no security validation mechanism
  • Sockets: highly general-purpose, but high overhead, usually used for network communication

5.2 Binder#

To solve the performance and security problems of frequent calls among the hundreds or thousands of apps on a phone, Google drew inspiration from the early BeOS/PalmOS systems and introduced a brand-new mechanism: Binder

Without Binder, there would be no Android of today

Binder cleverly uses memory-mapping technology. When process A sends data, the data only needs to be copied once into a specific memory region in kernel state, and process B can read it directly — safe and fast.

When app A calls a system service through Binder, the Binder driver forcibly and automatically stamps app A’s real identity tag (UID/PID) at the bottom layer. The system service takes one look at the tag and knows whether you have permission to make the call

The entire Android system (ActivityManager, PackageManager, the various hardware services) is built entirely on the vast communication network woven by Binder

5.3 The Minimal init vs systemd#

When we press the phone’s power button and the Linux kernel finishes booting, it needs to run the first user-space process (PID=1) to take over the system and bring up all the services

GNU/Linux today is basically ruled by systemd. It is extremely powerful and extremely complex, responsible for mounting file systems, configuring networks, managing background daemons, and even taking over the logging system

Mobile devices certainly don’t need such a complex general-purpose manager; what they need is extremely fast boot. Therefore, Android hand-wrote a very lean init in C

By parsing a series of plain-text script files called init.rc, it starts the core low-level services (such as vold mounting and logd logging) in a strictly prearranged order, configures SELinux permission policies, and then brings up the entire Android framework

6.1 The Marginalisation of Native ELF#

In Android, Google extremely discourages (and in the early days strictly forbade) developers from directly writing native C/C++ binary programs and running them as standalone processes in the system

Why? Traditional C/C++ programs are tightly bound to the CPU architecture (ARM, x86, MIPS). If you hard-code ARM instructions, phones with Intel x86 chips can’t run it

For a commercial mobile system dedicated to unifying the world, this kind of incompatibility is fatal

6.2 The Dalvik / ART Virtual Machine#

To let developers achieve write once, run shit everywhere, Google chose Java (and later Kotlin) as the Brahmin of the Android application layer

The .apk you download doesn’t contain machine code that can run directly on the Linux kernel at all; it has been compiled into a proprietary bytecode (Dex files) When you open an app, Android starts a dedicated virtual machine environment to interpret or compile this bytecode * In the early days (before Android 4.4), it was called the Dalvik virtual machine (using JIT just-in-time compilation, translating code while running) * Now it’s called ART Android Runtime, using a hybrid of AOT ahead-of-time compilation + JIT, translating bytecode directly into machine code when the app is installed or idle, greatly improving smoothness

6.3 The Component Model#

In traditional Linux, when you close a piece of software’s window, or kill it with the kill command, it’s completely dead But in Android, an app has no traditional entry and exit at all. Google forces all applications to be split into the four major components (Activity, Service, Broadcast Receiver, Content Provider)

When your app starts, when it goes to the background, when it is killed to free memory — none of that is decided by the code you wrote; it is forcibly scheduled by the core system service (ActivityManagerService) according to the phone’s current memory state and foreground interaction needs. This passive lifecycle management simply doesn’t exist on the traditional GNU/Linux desktop

7.1 The Radical Rewrite of Linux’s Multi-User Mechanism#

In a traditional Linux server, permission isolation is based on users

• For example, there are three real people on the server: Chongxi, xi and root. The system assigns them different UIDs. The Linux kernel strictly guarantees at the bottom layer that Chongxi absolutely cannot see the private data in xi’s folder On a phone, there is usually only one real owner, so wouldn’t Linux’s powerful multi-user isolation mechanism collapse?

Google activated its galaxy brain: since there aren’t multiple people, then treat every app installed on the phone as an independent user

This brings us to the Android sandbox mechanism: when you install Telegram, the system assigns it a UID (say 10045); when you install bilibili, the system assigns it another UID (say 10046)

• From the perspective of the underlying Linux kernel, WeChat and Taobao are not two pieces of software at all, but two parallel Linux system users who don’t know each other
• Using the kernel’s native UID isolation mechanism, WeChat naturally cannot read Taobao’s data in its private directory, and Taobao cannot interfere with WeChat’s operation. This is the Android sandbox. Old bottles, new wine

7.2 Zygote#

Since every app is in an independent virtual machine and sandbox, then every time you open an app you’d have to restart the huge Java virtual machine environment, and the phone would freeze long before that

To achieve lightning-fast startup and save memory, Android created a special process called Zygote

• When the phone boots, the system first starts this Zygote process, and gets all the Java core libraries and the virtual machine environment ready inside it
• When you tap the WeChat icon on the home screen, the system merely sends a command to Zygote. Zygote uses the Linux kernel’s extremely efficient fork() mechanism to instantly clone an identical copy of itself, and then runs WeChat’s code inside that clone

All app processes come from the same Zygote, and they share a large amount of underlying memory at the bottom layer (using Copy-on-Write technology), which lets an ancient Android phone with a few hundred megabytes of RAM run several apps at once

7.3 SELinux#

Early Android was frequently rooted by users; once you had su privileges, the sandbox mechanism existed in name only

To plug this hole, starting from Android 5.0, Google forcibly enabled SELinux (MAC), developed under the leadership of the US National Security Agency (NSA)

• Under SELinux’s rules, even if you are the root user, you cannot take a shit. All operations (reading or writing a file, calling a piece of hardware) must have an explicit whitelist authorisation in the system’s underlying security policy files, otherwise even the kernel will directly refuse to execute them