[fidotron]

You're making the precise mistake we're talking about: don't project from your experience of desktop Linux to Android. This equally applies for any Java platform too as the VM performance characteristics don't resemble any from the Sun/Oracle family.

The key thing is to understand what is involved to get an Android app to start up. This is terrifying when considering just the Dalvik case, but what most C++ types don't realise is that even if your app is using NativeActivity it means you are really subclassing this: https://github.com/android/platform_frameworks_base/blob/mas...

This means in order to load the native lib you first have to load Dalvik, a whole load of classes relevant to the app, allocate the whole Dalvik heap for the app, and then you rely on the Dalvik code to initiate loading of the native lib. As a result this only becomes worth doing if the gains you're going to make exceed those losses, but I find it's quite common for people to ignore the downside, as a few comments here indicate.

Storage to RAM bandwidth on these things is not exactly stellar, so as a consequence loading takes a while. To make things worse if you want to deploy all supported native architectures you're multiplying the native code size by four, since you will want two ARM builds (v5 and v7), one MIPS, and an x86. As a consequence I'm unaware of anyone that habitually includes all of them, and just putting ARMv7 libs in is the norm.

[lstamour]

The Google Play store will accept multiple build types and will deliver the correct builds to the correct phones automatically, no need for a fat binary.

While NativeActivity is interesting, for LOB apps we're much more likely to stick to native Android UI components, which means Android/Java activities. However, Loaders might then in turn use JNI as a model layer. I'm still working out the details myself, but I feel there should be a way for shared, cross-platform C or C++ code even if it relies on platform-specific UI and localization. The alternative, rather than JS, is probably Java2objc, used by Google for new developments.

[pjmlp]

Or Qt, as they support Android and iOS since version 5.2.

If you are doing commercial software, the licenses should be ok, but I am no longer sure how much.

Digia adopted the typical enterprise way of having sales people talk to you for price information.

[corresation]

The load time and memory consumption of a minimalist NativeActivity is so minuscule that it isn't worth discussion. Your argument beyond there seems to be of the good investment after bad variety -- that if you've made a marginal bad investment, you'd better keep making it just because. That is not good advice in any endeavor.

No one in this thread "ignore the downsides", and your point seems actually very undeveloped: After you've paid that unavoidable, very small initial price (that of course a fully managed app pays as well), you then have 100% minimal native app, using that legacy or cross platform code at full, 100% native speed, with no GC taxes, etc. There is no magical overhead just because you originally started with a native activity.

This is certainly not to say that native is the way to go, because if you're going to make heavy use of the Android API outside of the pure native elements like OpenGL, you're going to just cause yourself a lot of hassle, but most of the anti-native argument seems to derive from nothing at all.

And the ARMv7/v5/MIPS/x86 thing is just strange. Yes, it might be a consideration in some cases (although if it matters 9 times out of 10 you can set a flag and there you go), it is quite a departure from the claims about C++.