Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In the Android-y part of Android, yes, they use ART, which is abstracted.

But, they also give app authors the NDK. How do you think Android knows whether it's libc or your app making a syscall from native code?

It doesn't - you're allowed access to full Linux-land. The syscall numbers and userland EABI for Android are the same as for any other Linux. They use a different `libc` from most GNU/Linux (one of a few places this wonderful turn of phrase actually makes sense) flavors, but this is no different from Alpine Linux using `musl` instead of `glibc` for example.

As such, you can use `musl`, `glibc`, or non-libc based environments (Rust, Zig) on Android without issue. You can run any C you want, either by porting it to `bionic` (most termux apps, although they support glibc now), statically linking your own runtime (Rust, Zig, etc.), or abusing the dynamic linker into making glibc work (termux-glibc, I think).



> you're allowed access to full Linux-land

Yes, but there are strict SELinux policies forbidding you from accessing certain "dangerous" stuff like execve(), which may end up killing native terminal emulators like Termux (despite Android not forbidding dynamic code execution elsewhere, Play Store policies aside).

https://github.com/termux/termux-app/issues/1072

https://github.com/termux/termux-app/issues/2155


Sure, and this VM solution is the exact path forward for “install stuff in a box” solutions as Android move towards trying to enforce w^x, which is probably why they chose a full Linux VM as their demo app. Emulators and games and apps with embedded JIT will be harder to deal with.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: