14 ms·
> Because Linux APIs were never really intended to be called by NDK developers, only the POSIX subset and Android public native APIs. That's not even slightly
by kllrnohj 8y ago
> Because Linux APIs were never really intended to be called by NDK developers, only the POSIX subset and Android public native APIs.
That's not even slightly true? Android doesn't pretend to be anything but a Linux system, with all the Linux details shining through in all their glory.
There is a seccomp policy that blacklists some syscalls, but it's only 17 out of 271 for ARM64 and it's things like setuid or reboot which you won't have permission to do anyway. Other than that you're completely free to go nuts with raw syscalls, you're in no way, shape, or form stuck going through a POSIX layer.
- pjmlp 8y agoYou can try to do it, but good luck guaranteeing that your APK doesn't crash and burn across Android OEMs and people want to still give you money. These are the only APIs devs are officially allowed to touch. https://developer.android.com/ndk/guides/stable_apis https://developer.android.com/ndk/guides/stable_apis Anything else is "works on my phone" kind of thing.
- kllrnohj 8y agoNo, that's just wrong. It becomes your responsibility to ensure your syscalls match and are available on the kernel you're actually running on which you may be confusing with "not allowed to use". And very nearly all of the time this is a complete waste of everyone's time since the syscalls are a direct mirror of what's in libc anyway just with libc doing the compatibility for you. But just to really prove that you can absolutely syscall on Android, one of the largest, most widely deployed & shipped NDK/SDK apps does it to workaround a missing futimes in bionic: https://cs.chromium.org/chromium/src/base/os_compat_android.cc https://cs.chromium.org/chromium/src/base/os_compat_android....