A forked version of it because Google didn't want to deal with "No." from the Linux maintainers when they were massacring the kernel into mobile ready form.
The point is that distro patches are trivial compared to Android patches. Your distro will continue to work fine with a vanilla kernel unless it's using an esoteric configuration, and even with esoteric configurations it's relatively easy to include necessary patches to vanilla kernel.
Compiling and using a vanilla kernel instead of the distro one is straightforward and easy job for people with basic knowledge of source building. It's not a job for "very few brave souls". The reason many people use distro kernels is because they're good enough.
OTOH any consumer Android device requires millions of loc patching to a several years old version of Linux kernel just to boot.
AFAIK, vanilla kernel improved a lot in terms of functionality, so Android can work on vanilla kernel if code will be adapted to use these new APIs instead of Android homegrown APIs. Anyway, it's open source, so anybody can use Android patches without restriction. I see no problem here. Kernel version 4.4 is fresh enough for me: https://android.googlesource.com/kernel/common/+/android-4.4... .
BTW. I'm not sure if my distro (Fedora) will work with vanilla kernel without Redhat patches. There was times when it wasn't. I compiled kernel myself with my own patches and configuration in between 2001-2008.
> AFAIK, vanilla kernel improved a lot in terms of functionality, so Android can work on vanilla kernel if code will be adapted to use these new APIs instead of Android homegrown APIs. Anyway, it's open source, so anybody can use Android patches without restriction. I see no problem here. Kernel version 4.4 is fresh enough for me: https://android.googlesource.com/kernel/common/+/android-4.4.... .
What I'm trying to tell is it being possible doesn't mean it is practically possible.
Android specific API or subsystems are one part of it, then there is device specific patches. Kernel and patches being open source makes it possible to switch to a new kernel version but I've almost never seen that exercised. Few years ago the stats were that a typical consumer phone contains millions of line of patches on top of the selected upstream kernel version. It is not feasible to rebase a typical device to use a newer kernel version, and it really shows: I've seen only few phones that got a newer kernel version than it originally shipped with, switching from an ancient kernel version to only slightly newer but ancient kernel version.
> BTW. I'm not sure if my distro (Fedora) will work with vanilla kernel without Redhat patches. There was times when it wasn't. I compiled kernel myself with my own patches and configuration in between 2001-2008.
I'm pretty sure it'll. Linus himself uses Fedora and he likes his kernel pure vanilla :)
Isn't this true for desktop GNU/Linux too? I mean, last I checked, Debian kFreeBSD would be similar enough to Debian GNU/Linux as long as you don't drop to the console - the equivalent of which would be adb shell.
No, because you get full access to the OS APIs, so any application is exposed to the implementation specific behaviours of POSIX and OS specific syscalls and paths.
Where in Android, you just get Java and a tiny bit of C and C++.
Check the NDK documentation, Google provides a list of the set of APIs any NDK application is allowed to use.
Since many used to ignore that list, starting with Android 7, any app that uses unauthorised native libraries will get killed.
I'm not sure of numbers but AFAIR both kfreebsd and khurd have 80% of packages in the archive and even getting to this level requires Linux compatibility hacks like procfs support
The majority of APIs are not exposed to NDK users, only to OEMs.
Google could release lets say Android 8 with another POSIX compliant kernel and the only apps that would notice are the ones using non official APIs.