Because Android's OS APIs are in Java for a reason. Yes, if you insist on using C++ with the OS APIs, you are pushing a square peg into a round hole, so enjoy JNI.
iOS and UWP also were not designed with the intent to use single binary on any CPU architecture, independently from any appstore that could recompile for you.
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.
> iOS and UWP also were not designed with the intent to use single binary on any CPU architecture, independently from any appstore that could recompile for you.
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.
> Application's bytecode is uploaded to the store and gets compiled to each supported architecture using the so called "cloud compiler".
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.
In any case that was just an example.
Android has nothing like Objective-C++ or C++/CX for easy interoperability with the OS APIs.