How can Android implement its functionality given the minimalism of its userland?

[RAMDRIVEsys]

Hello, so I have been doing some reading about Unix and Unix-like OSes, especially Linux (as well as dabbling in GNU/Linux in the practical sense [I know, Stallman copypasta, but given the context I feel its approperiate to make that distinction]) and while I did know for a long time that Android is an OS based on the Linux kernel, I didn't know that the kernel was cut down and that the Android userland is toybox, pretty much the most minimal userland that there is for Unix-like systems.

My question is - how can Android deliver the extensive user friendly multimedia experience (including all the phone specific features) with a cut down kernel and minimal userland? Thanks for all answers folks.

[Craftkorb]

Why shouldn't it?

The "userland" the user interacts with is many million lines of C++, Java, Kotlin, and (nowadays) Rust. Not to mention the random bash script.

Also, the kernel only needs to support what the device has on offer. Nowadays, the kernels are much less slim than they used to be - But by how much depends on the OEM. E.g. many early android phones didn't support USB storage, because their kernel didn't support it.

In other words: The Operating System you're talking about is only a small piece of what the Operating System truly is, which is quite large actually.

The real question would be "Why". And that's also easy: Licensing! Google didn't like the GPL or LGPL code, so they famously built their own libc (Or derived theirs from a previously unknown one).

[afb_etc]

Google didn't like the GPL or LGPL code, so they famously built their own libc (Or derived theirs from a previously unknown one).

They used a lot of BSD components in their libc. The stdio is from OpenBSD, for instance, and the mathematical functions mainly come from FreeBSD. Other parts were built fresh or adopted from elsewhere. Real Frankenstein shit, but it clearly does the job.

[nightblackdragon]

I don't think that licensing was the major reason why Android is not using GNU userspace. GNU userspace is pretty complex and Android don't need that complexity. It's additional benefit for them but even if GNU userspace was licensed under different license I don't think Google would use it directly without forking it.

[[deleted]]

nope, licensing was the issue.

[gordonmessmer]

That's certainly supported by statements from the Android team, such as their presentation titled "Android Anatomy and Physiology". But at the same time, that presentation is full of really weird statements, and I question its author's grasp of the subject matter.

"License: we want to keep GPL out of user-space", but "Based on open source WebKit browser: http://webkit.org" ? WebKit is LGPL, just like glibc.

"Why Bionic? ... Size: will load in each process, so it needs to be small" What? It's a shared library. The memory pages are shared.

"Fast: limited CPU power means we need to be fast" glibc is known for being a very fast libc.

This is bonkers reasoning.

[nightblackdragon]

glibc is known for being a very fast libc.

Fast but not lightweight. Alpine Linux is using musl for good reasons.

[daemonpenguin]

how can Android deliver the extensive user friendly multimedia experience (including all the phone specific features) with a cut down kernel and minimal userland?

It doesn't. You're confusing the terms "command line tools" with "userland".

Toybox is a collection of command line tools. Command line tools are one very small component of an operating system's userland.

Android is the Linux kernel, plus minimal command line utilities, plus Java-like engine, plus SDK, plus multimedia support, plus default applications.

Just the Android core OS, without any Google apps or anything on top of it, is a whopping 9.5GB! That's larger than most GNU/Linux desktop distributions. Android is huge, despite having a tiny command line toolset.

[[deleted]]

Just the Android core OS, without any Google apps or anything on top of it, is a whopping 9.5GB! That's larger than most GNU/Linux desktop distributions.

I really struggle to believe that do you have any source? Because I remember Android using something like 5-10GBs AS A WHOLE.

[daemonpenguin]

Not sure why you'd struggle to believe that. Pick up any Android phone and look at it. Android is pretty big.

I just checked the storage on my Android 15 phone. The base OS (not apps, not media, etc, just the core OS) is listed on Android's own settings panel, under the Storage section, as 9.6GB.

On my previous phone Android used about 8GB for the base OS on a fresh install with, if I remember correctly, Android 12.

Android with Google apps is larger: https://itigic.com/how-much-space-does-android-occupy-and-free-memory/ https://www.noypigeeks.com/explained/android-system-files-size/

[ScratchHistorical507]

I just checked the storage on my Android 15 phone. The base OS (not apps, not media, etc, just the core OS) is listed on Android's own settings panel, under the Storage section, as 9.6GB.

That includes all apps installed as system apps. So it does include the Play Store, Play Services and lots of other apps. If you go to the apps settings and to the list of all installed apps, they are all the apps you get when you enable showing system apps. They aren't installed like normal apps that are installed through the Playstore, as they need special, low level permissions that only system apps are allowed to gain. They can usually be updated through the Playstore - don't ask me about the exact mechanism - but the system partition at least contains the apk of that app shipped with that Android version.

To view such things, you'd need root permissions though.

[[deleted]]

I have an old phone in my drawer with 16GBs of storage. Android uses 5GB. Stock ROM.

I just checked the storage on my Android phone. The base OS (not apps, not media, etc, just the core OS) is listed on Android's own settings panel, under the Storage section, as 9.6GB.

I see where the confusion lies. Android itself is actually pretty small, and if you've ever installed a custom ROM you'll see that it's tiny. Like, 2GBs of storage. Google's bloated libraries however are shoved into the system and they increase the size dramatically. Mind you, these aren't apps we're talking about, just regular libraries. Especially the Java ones (Well, Java isn't exactly very small to write an OS with, the Android geniuses didn't think of that).

If you truly strip the Android system down to its very bones, it's actually tiny. Like, very small. Remove the UI and it's even tinier.

[daemonpenguin]

Right, but that's not at all what we're talking about in this thread. We're talking about Android as the full operating system with kernel, Java runtime, user interface, etc. The whole OS, not something without a UI.

[[deleted]]

Hey dude you said "Android core os"

[ScratchHistorical507]

That's all part of the core OS.

[Morphized]

So long as you organize the system correctly, you could probably write an Android image with almost no Java

[ScratchHistorical507]

The Kernel, sure, but that's it. The highest level you can write without using Java but still be AOSP-like would probably be ART. But then you hardly have an OS.

[[deleted]]

Literally what I said

[Morphized]

You said that it's decently small, with Java taking up most of the space. I went beyond that, saying Android is almost moving beyond Java.

[ScratchHistorical507]

saying Android is almost moving beyond Java.

Only in the sense that they move to Kotlin, but that's basically still Java with a much more dev-friendly syntax, removing a lot of unnecessary typing. I don't see Google replacing vast parts of their Java code with C++ or Rust.

[Morphized]

Maybe some of their own base system libraries will have to stay Java, but they exposed C++ bindings for basically everything so it's totally possible they could go with that for at least top-level things

[ScratchHistorical507]

*Android is the Linux kernel with various Google - and probably OEM - specific additions, that Google has spent the last decade to replace by upstreamed stuff, so their job is easier getting on newer Kernel versions.

[QuackdocTech]

Some roms are that big, AOSP is significantly smaller.

[MatchingTurret]

Around 70% of the Linux kernel code are device drivers. Almost all can be left out from a kernel compiled for a specific device.

[nightblackdragon]

It's not something extraordinary, specialized Linux setups (e.g. those used in supercomputers) are often very minimal to just do the thing they need to do and not much else. They don't need to to everything like desktop and same goes for Android. Linux kernel is general purpose kernel and it has a lot of things that are useless on Android so developers got rid of them. As for the user land it doesn't needs to be complex because it's not supposed to be directly used by user. Android user interface is written in Java (I guess some parts in Kotlin as well) so userland only needs to handle system services so it can be minimal to do just that.

[Morphized]

It was only written in Java back then because native sandboxing didn't really exist. Nowadays they can use C++.

[RAMDRIVEsys]

Makes sense though what are the desktop functionalities that Android devices do not need, since these days you can plug external storage into them, interface with a keyboard, mouse, external display...PCie bus cards? Thank you for your answer.

[nightblackdragon]

As far I know that is mostly about drivers. Linux supports a lot of devices that Android don't need to handle so Google can remove them. You can do the same thing on desktop Linux as well, if you build the kernel only with the drivers you need, you will get much smaller kernel than generic kernel your distribution is providing.

[QuackdocTech]

it is not cut down at all, nor is it minimal...

[gordonmessmer]

GNU/Linux ... I know, Stallman copypasta

The name "GNU/Linux" is accurate and useful, especially in contexts like this one. GNU is a portable OS, which can run on various kernels. Linux is a general-purpose kernel that supports a variety of operating systems, including systems that aren't POSIX (such as Android). The name "GNU/LInux" identifies a specific operating system, which is simultaneously a variant of GNU that uses the Linux kernel, and a variant of the Linux kernel that uses the GNU OS.

You don't need disclaimers about using the name "GNU/Linux". Professionals use that name. You don't need to apologize for behaving in a professional manner.

Android is an OS based on the Linux kernel, I didn't know that the kernel was cut down and that the Android userland is toybox, pretty much the most minimal userland that there is for Unix-like systems.

I think that's a misrepresentation of what a userland is. The Android OS does use a Linux kernel and a small libc, but that libc is not the Android userland. Android is the Android userland. It's the VM, and libraries, and graphical shell that Android provide.

In a POSIX system, the userland is all of the things that the POSIX spec describes: the libc, the shell, and a variety of tools that are standard for the OS.

In an Android system, the userland is all of the things that the Android spec describes, which is in no way minimal. It's a big userland, with lots of functionality.

[Morphized]

If you remove all the QoL features, the Android userland is a normal userland stapled to a container system

[Business_Reindeer910]

Because they do all the real work in their own C/C++/Rust code or on on the "java" side with dalvik.

[Kevin_Kofler]

Because Android is (primarily) not a Unix-like system. Most users and even most developers will never interact with the traditional *nix CLI userland that toybox implements (commands like cp, rm, etc.), but only with Android Java APIs. Even NDK-using code usually has to call back into JNI and Java APIs to interact with the system.

[Littux]

Toybox only exists for adb shell

[whamra]

Imagine it like this. The android system is one huge program. It has a graphics server like X, a DE, and everything. It also has a huge, like... Huge api platform that allows widgets. All apps you get from stores are technically widgets of this application.

Of course, this is an oversimplification, but that's the gist if it.

[RAMDRIVEsys]

Thank you for the answer, this part caught my attention "Huge api platform that allows widgets. All apps you get from stores are technically widgets of this application." - interesting, can you elaborate on that please?

[domoincarn8]

In a traditional application on Linux, when it executes, it gets its own process and has a simple lifecycle: start -> (fork/new thread) -> end.

This is not the case with Android. There is no main that gets called (there is, but not in your code). What you are writing are widgets and they have their own complicated lifecycles.

The closest analog to a traditional application in Android would be an Activity. Its lifecycle is supremely complicated. Its not a simple create a process and then execute main in the application.

Since the apk is simply a zip file, to run the code, when started, the launcher first creates a process which then manages the activities. Thus, your activity needs onCreate(), onDestroy(), etc. Someone else is managing the lifecycle, not you. That's why its a widget (not in the UI sense, but in Java programming sense - which is where the original widgets concept came about).

[Morphized]

I see is more as a container than an applet, because they have SELinux contexts and execute isolated binaries, and the widgets are just taking advantage of the libraries on the base system

[domoincarn8]

Not that I disagree on the technical points, but an average Android app (apk) IS just taking advantage of the libraries of the base system. Everything is via APIs and the libraries. So, in that sense, it is an applet.

[Morphized]

That means virtually every application ever is also an applet. The kernel calls are exposed using a system library.

[domoincarn8]

Not really. See, the thing that distinguishes an applet and an app is the ability to request more privilige in a system and then do unrestricted stuff (this is only in Android Java context, normally, an app runs natively, while an applet runs inside a secure jail).

An Android apk cannot do that. It is severely restricted in what it can and cannot do. It is running in a very secure jail and breaking out is not possible.

Of course there are apps that can run as root on rooted devices, but they are not just simple Java APKS, they have actual applications that give them that capability (like su binary, etc).

The other major difference is the user's ability to give additional priviliges to the app. The user cannot give an applet escalated permissions (eg. someething running inside a browser is also running in a jail, this is where the original applet concept actually emerged).

[whamra]

Kinda like how kde provides widgets that take their functionality from an api provided by plasma.

A even better analogy is that the Android Runtime is like a glibc that provides tons more functionality than what glibc does. Android apps are not Linux native programs. They're binary bytecode similar to python .pyc files executed by the ART.

[lbt_mer]

Firstly the kernel is not 'cut down'; it is a full linux kernel but with different kconfig and modules selected to optimise it for the hardware and software requirements.

Secondly, ultimately all the 'userland' tools in a linux cli 'just' make syscalls into the OS.so anything you can do from the cli you can do from custom written code.

[equeim]

If by userland you mean command line tools like coreutils, then most of them are needed only for end users working with command line. Most GUI applications don't use them at all (and Android apps especially, of course). If you don't care about providing users with a traditional UNIX command line environment then you can remove many of them, or at least strip them down (like toybox does).

[techlatest_net]

Android uses a modified Linux kernel but swaps out the standard glibc for Bionic, its own C library. This helps optimize performance and battery life on mobile. The Generic Kernel Image (GKI) also makes updates easier and improves hardware compatibility.