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.
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.
They dont use GNU or glibc or systemd
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.
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.