NDK team doesn't look like it's expansive or prioritized at all, so I doubt they have resources or will to do that. TBH I'd rather they focus at improving the tooling and debugging, we can ship our own libraries with our own options compiled in. Heck even on iOS we have to ship a custom SQLite to get all the needed capability.
Google has one of the largest software engineering populations of any company in the world. It supports one of the largest developer ecosystems in the world. Games are the largest catagory in their ecosystem. 2 engineers supporting the NDK...
It wasn't there until 2.2, only got added due to community pressure and they always did the minimum amount of work.
When the migration to Android Studio was announced, we got left with no migration plan.
Only after JET Brains announced CLion, almost 2 years later, did they announce the migration to Studio.
Likewise they moved into Gradle without plan for C NDK support and it took three generations of build tools until they decided to settle on CMake.
As an earlier commenter mentioned, games are one of the biggest app categories and many games rely on the NDK. Pro audio could be another big category, but I think Apple has the market sewn up there because Android is still way behind.
(I'm not saying that there's anything inherently unreasonable about that, although I happen to disagree with the decision. But these things cost money and they decided they didn't want to spend the money.)
Most likely due to game development community.
Specially when compared with the tooling support C and C++ enjoy on iDevices and UWP.
So anyone that wants 2D graphics from NDK side either needs to call into Java, or bring their own library on top of OpenGL.
And the whole mismanaged way how the C++ IDE and build system migration was handled.
What you want is stable APIs for things that interact in fiddly ways with the rest of the system, so they're more easily managed at the OS level. Networking, shared databases. (Edit to add: localization)
zlib is nice to have, but it's also really portable and lightweight. It would be easy for apps to bundle their own copies. Something like libcurl is a lot more awkward (what do you use for https? bundle your own SSL too!)
In any case that was just an example.
Android has nothing like Objective-C++ or C++/CX for easy interoperability with the OS APIs.
Also, given that Google forked Java, they could have added something like CNI insteand of forcing everyone the JNI pain.
iOS also is not easy to use with any language, it assumes ability to link with a module written in ObjC. The pain of using UIKit with Python is comparable to using JNI.
It seems you never did UWP development.
UWP was designed to be architecture independent since Windows Phone 8.
Application's bytecode is uploaded to the store and gets compiled to each supported architecture using the so called "cloud compiler".
iOS development has moved into that model with bitcode on iOS 9.
Also there have been several C and C++ compilers across the years that could generate single binary on any CPU architecture.
For example compilers for OS/400, TenDRA, PocketPC.
> iOS also is not easy to use with any language, it assumes ability to link with a module written in ObjC. The pain of using UIKit with Python is comparable to using JNI.
Python is not a platform language on iOS SDK, C and C++ are platform languages on iOS, Android and UWP SDKs.
A good lesson in terms of productivity, is to only use SDK supported languages when writing production code any OS.
That's why I wrote: independently from any appstore that could recompile for you.
Google was and is under different constrain, that you refuse to acknowledge: everything, that puts an application onto the device, must be able to run locally at the development system. Amazon store, F-Droid, or whatever the Chinese or Russians are using cannot depend on Google Play Store to recompile for them. The result has to run not only on any combination of ARM/Neon/VFP3, but also on Intels, MIPSes or some future architecture, that someone somewhere used or will use in the Android device.
Yes, they could use pNACL or LLVM bytecode, or whatever. They used a higher level one, dex. Their target was Java class hierarchy, they didn't want their developers to reinvent strings and collections all time.
> Python is not a platform language on iOS SDK, C and C++ are platform languages on iOS, Android and UWP SDKs.
C and C++ are not platform languages for Android. Literally, just read the first two paragraphs of Android NDK's "Getting Started" document. Using C/C++ is only for certain scenarios, that don't require the rich platform APIs. These are written in Java and if you are going to use non-JVM language, you are going to go through the same pain as if you were using Python with ObjC frameworks.
Even if you don't need a whole 2D library, it would be very useful to have a stable API for reading the system fonts, so apps don't have to ship their own.
I bet many Android devices already have at least 9 copies of sqlite, since so many apps ship their own copy.
Why is the NDK so underpowered? Why are they so reluctant (or unable) to publish some useful, stable native APIs? It's missing things like curl, sqlite, icu, OpenSSL. Most of these are built into the OS but not accessible via the NDK. (OpenSSL isn't a great library, I know, but it's patchable. And they could start now with something better.)
The only useful native third-party libraries you get are: zlib, OpenGL ES, OpenSL ES.
Apart from that, there are a bunch of wrappers for a small subset of Java APIs (AssetManager, Bitmap and so on). These are tedious to use, and seem to have been written by hand so in some cases they're buggy -- for example, incorrect string handling in AStorageManager: https://code.google.com/p/android/issues/detail?id=41983