It is also a highly modified kernel, extremely reduced. They do all filesystem stuff in userspace for example, which is pretty cool. And they add a ton of garbage out of tree drivers.
glibc is key here, it’s what most linux distros use. One of Google’s vendor-lock moves was to start using their own libc implementation, making it incompatible with everything else.
They dont use GNU or glibc or systemd
Lots of distros don’t use systemd, and a few non-AOSP distros don’t use GNU userland or glibc, Alpine for one.
Just saying what some guy told me.
It is also a highly modified kernel, extremely reduced. They do all filesystem stuff in userspace for example, which is pretty cool. And they add a ton of garbage out of tree drivers.
glibc is key here, it’s what most linux distros use. One of Google’s vendor-lock moves was to start using their own libc implementation, making it incompatible with everything else.
I can imagine that theirs is safer and more suited for targeted devices. Linux is extremely generalistic and has a ton of cruft.
But I have never looked at their code or tried to port a Linux app to Android. The #Krita devs might have some insight here.
For targeted devices so is Gentoo. Their edge is having access to proprietary drivers.
If it’s written in portable C you can use the Android NDK/SDK to cross-compile it for the 4 archs they support. I do it at work.
So how is this vendor lockin?
Not an actual lock-in as they (still) provide tools to cross-compile and the source is (still) available, more like a vendor push-out if you insist.