[pjmlp]

Because Android is not Linux, as much as some pretend it is.

In fact, given the official public APIs, Google could replace the Linux kernel with a BSD, and userspace wouldn't notice, other than rooted devices, and the OEMs themselves baking their Android distro.

[grosswait]

It absolutely is Linux, and yes the JVM could absolutely run on something else. But it is Linux and you can run Linux binaries directly on it - that just isn’t how it is used by end users.

[akdev1l]

The JVM has nothing to do with Android. There is no JVM running android apps.

There was Dalvik VM at one point but now it’s just the Android Runtime.

[pjmlp]

No you cannot, the NDK has a specific set of oficial APIS, and the Android team feels in the right to kill any application that doesn't follow the law of Android land.

Some folks like the termux rebels, occasionally find out there is a sherif in town.

> As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code can link against at runtime. As a result, if your app uses any private symbols from platform libraries, you will need to update it to either use the public NDK APIs or to include its own copy of those libraries. Some libraries are public: the NDK exposes libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are private, and Android N only allows access to them for platform HALs, system daemons, and the like. If you aren’t sure whether your app uses private libraries, you can immediately check it for warnings on the N Developer Preview.

https://android-developers.googleblog.com/2016/06/improving-...

These stable APIs,

https://developer.android.com/ndk/guides/stable_apis

[stevenhuang]

That's all user space platform specifics, it has no relation to your previous statement where you said 'android is not linux'.

Someone can statically build a freestanding executable/so targetting arm64 linux (specifically the right android linux kernel version) and it will run fine on Android. The syscall interface, process model, file descriptors, signals, memory mapping, all of this is Linux, this is what people mean when they say Android is just Linux.

[pjmlp]

Yes, exactly PlayStore isn't GNU/Linux, normies don't use ADB.

[tadfisher]

What's amazing about Linux is that you don't have to use the system's libc, and you don't have to use dynamic linking.

That said, newer Androids use seccomp to restrict which syscalls you can use, basically to what bionic exposes anyway. This doesn't seem to affect Termux and friends, which can apparently run full X11 applications without root.

(edit) Notably, splice() is still callable, so maybe the POC needs to be tweaked...

[pjmlp]

Yes, at which point it isn't GNU/Linux, rather something else built on top of the Linux kernel.

As for termux,

https://wiki.termux.com/wiki/Termux_Google_Play

[esseph]

https://www.androidpolice.com/google-support-linux-kernels-a...

Google relies on Linux LTS kernels. When the Linux LTS team dropped support from 6 years down to 2 years, Google stepped in to cover the 4-year gap.

It is Linux. It's basically a distro.

[pjmlp]

When people say Linux they mean GNU/Linux.

[cyphar]

In common parlance, yes -- because there is no practical distinction. But in cases where something is just using the Linux kernel without GNU and other common userpand components (and there is a practical distinction) then it's definitionally untrue to say that it's "not Linux" if you really meant to say "it's not GNU/Linux".

[esseph]

I've always thought this was extremely interesting: https://chimera-linux.org/

[nonameiguess]

Alpine Linux is not using GNU. I'm sure there are others. No definition you can ever come up with will have no exceptions in widespread use. Live with it.

[grosswait]

Maybe. Depends on context, and in this case the context means, no I do not mean GNU/Linux

[dzaima]

That's specific libraries, when using the default linker. You could construct that same behavior on desktop linux too. And you can avoid it equally well on Android - you can statically-link things just fine, you can use libraries you actually control, and presumably use a custom linker if desired. It's utterly non-surprising that "you run code you don't control" results in "said code...can do arbitrary things for unsupported use". (Never mind that, instead of a "sherif", they could've just renamed all private symbols, or just naturally replaced them over time, breaking your code all the same, just in a more confusing way)

Also some obligatory Linux vs GNU/Linux comment. (and it's not like GNU/Linux doesn't ever change under your feet - see the glibc DT_HASH debacle)

[anthk]

- Waydroid

- Is totally Linux