No they don't, you cannot use C in Android outside the NDK, and even on the NDK you need to go through JNI for 80% of the OS APIs.

This is the only set of APIs exposed via a C API to Android applications,

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

You can argue that JNI technically is exposed via C, yeah if you ignore the JVM/ART semantics that go along with it.

Likewise on Windows, technically you can use bare bones structs with function pointers to deal with COM, use CLR COM APIs to call .NET via reflection, and a similar story with WinRT, but it is not going to be fun, and then there is the whole type libraries that have to be manually created.

▲

dagmx 3 days ago | parent [-]

I think we’re talking past each other, and you’re largely repeating what I already covered .

My original response delineated between levels of the stack, and also already called out that Android requires you to use the NDK/JNI to use the C ABI.

I also specifically called out windows as well.

My point is that the original persons distinction of what supports a C ABI is conflating different levels of the stack. It’s not a useful distinction when describing the platforms and the windows case is why I quote “PC” since desktop semantics vary quite a bit as well

A more useful delineation of why mobile dev is harder to just do an asm hello world is that mobile dev doesn’t really have a concept of CLIs without jumping through some hoops first. So you have to pipe such a thing through some kind of UI framework as well.

▲

pjmlp 3 days ago | parent [-]

If userspace needs to use NDK/JNI ABI to call the Linux C ABI, naturally the OS ABI isn't the C ABI, by definition.

▲

dagmx 3 days ago | parent [-]

Why not? The NDK/JNI calls are still in user space themselves. So what delineation are you trying to make here?

	▲	pjmlp 2 days ago \| parent [-]
		How userspace applications talk to the kernel subsystems, in a legal way without hacking the operating system architecture.