I hate to distract, but if this project is of interest to you, you should also check out https://developer.nvidia.com/tegra-android-development-pack It's a one-stop installer for the complete Android native development suite, a CPU profiler, a GPU debugger, Eclipse integration for native debugging and the best Visual Studio integration I've found yet (I have not yet tried Android++).
To my knowledge, Nvidia is doing more to improve the native development experience on Android than any other group on the planet (including Google). This is my plea to ask as many people as possible to try their package and give them feedback just so that they'll be motivated to put even more resources into the project.
It is quite awesome of Natural Motion to release Android++ to the public. Given their "No Hardware Restrictions" feature I understand their concern with relying on Nvidia. However, from working with Nvidia, I'm quite confident that Nv's primary concern is getting people to make high-performance games on Android at all. I would encourage Natural Motion and Nvidia to reach out and find ways to help each other reach their common goal -beyond simply providing friendly competition.
However, if you're using C++ for portability for any sort of non-realtime needs you've lost your marbles, and would be better off with JavaScript (no, really) and/or platform specific code to leverage the class libraries of the respective platforms. C++ heavy apps on Android are larger, use more memory, and load less quickly. This isn't obvious if you're used to other worlds, but it is a side effect of how pervasive Dalvik is on the system. Even if most of your app code is in C++ it's still easy to get screwed by a GC pause caused by where you have to interface with the framework.
Much of the underlying problem here is that speed-wise Dalvik just isn't very good. It wasn't even competitive with J2ME VM performance when it first appeared, and took a long time to get close.
With all that said, native debugging has been a sore point forever, and any improvement in that area is welcome.
Maybe if you're starting from absolutely nothing. If I had non-trivial functionality already written in native code then I suspect I'd rather write JNI bindings than do a complete rewrite in Java.
I'm also skeptical of 'use more memory' and 'load less quickly'. Even the GNU C++ standard library on an x86-64 desktop is a less than a megabyte. I can't imagine that being significant in either of those problem areas.
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.
Citation required, as this is entirely the opposite of every experience I've had actually building apps that use significant native code. What are you basing this claim on?
There really isn't anything magical about Dalvik (or ART) -- it is a per instance runtime. C++ code doesn't suddenly become heavier or slower to load because of Dalvik.
And of course the overwhelming majority of games are mostly built using the NDK.
First, I'd hesitate to use the phrase "native C++ UI stack". Mozilla's UI framework is XUL, which is a mixture of JS and XML. Presumably there's C++ underneath, but based on my reading it's a mixture of web-based technologies.
Second, because the original Firefox for Android UI was written in XUL, they had to load the entire Gecko architecture in order to render any UI. That was ultimately the performance issue, not "interacting with android frameworks".
Because of that, the goal of the rewrite was to be able to show the UI immediately, while loading the Gecko stack in the background.
There's some good info on this at http://starkravingfinkle.org/blog/2011/11/firefox-for-androi... and http://www.mozilla.jp/static/docs/events/vision/2012/04-mark... .
Obviously, there is the case where the code shop may have other project assets tied into the VS ecology-dev system but is that the only case?
Even something as basic as Tortoise SVN is a massive workflow improvement over trying to use TFS.
And test integration got vaguely good in this VS maybe? I wouldn't call it good or mature. Maybe it was 2012, they happened so fast I barely used 2012. I remember trying to use it in 2010 and clicking on failed tests wouldn't take you to the failing line or the failing test, it would do bizarre things like expand an info pane that didn't actually have the info you needed. It was such a complete failure that they totally ditched it in VS 2013 and had a whole new UI.
And don't get me started on the god awful profiler they've added, what a disaster.
Half the things they add in VS suck, but are better than nothing.
Oh and has one of the best vim integrations.
http://newsroom.intel.com/community/intel_newsroom/blog/2013...
I assume the Samsung Galaxy 3 Tablet is a big "x86-Android" platform, which would obviously be incompatible with ARM-Android.
If you have some code optimized for a particular ISA, say a function which uses ARM NEON, you also have APIs in the NDK which allow you to detect which ISA you are running on and dynamically load the appropriate for that particular architecture. However, this is an optional feature. For pure C/C++ code without ASM or platform-specific intrinsics, compiling for multiple ISAs is trivial using the NDK tools.
From the rationale page:
"Large numbers of these developers world-wide use Visual Studio as their primary IDE. Either by preference, or other external factors."
I wonder if having fairly good tooling is one of those factors? And if so, will this encourage people to stick to Visual Studio?
I'd recommend developers to try Qt Creator for Android (there's no requirement to use Qt with it if you don't want to). IMHO, for native development it is already good, improving rapidly and has the advantage of being cross platform and Open Source, though it's build system (qmake .pro/.pri) is arguably worse than MSBuild. Once Qbs support is finished I'll happily retract that statement.
Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.
In general, you should only use the NDK if it is essential
to your app—never because you simply prefer to program in C/C++.
I recall the fireside android team chat one time (two years ago?) that went something like:
Question: So what about the NDK? You can't beat native for performance...
Android team member: *laughs* ... well, you can't beat java for portability
Comment from audience: Unless you want to use your code on another platform...
<awkward silence, discussion moves on to next question>
However,
- Google has managed to fragment the Java world
- Pushes Renderscript instead of OpenCL
- Forces everyone to go via JNI to access Android APIs in C and C++ land
They are no better than the other players.
I am actually curious to find out what are their plans in regard to ART. Only replace Dalvik, or go further in terms of what will be the set of supported languages.
I don't have any stats on that, but you can check out the following games made using the open-source C++ framework Cocos2d-x that the developers asked to be featured:
Personally, I'd like to get some reuse out of my iOS code. I'd do more C++ if I knew that I could reuse it. Of course, Objective C could actually be portable too.
I develop on Linux (Ubuntu), with a make file set up to build for desktop or for Android with one command, and it just works. Took a little bit of time (maybe an hour) to get the build scripts set up for Android initially, but after that it's been great.
As I'm writing a game I'm using entirely custom UI etc. so I don't worry about not being able to access the normal Android UI classes and such. I do a little bit of JNI for loading resources but that was trivial to write. My game engine works exceedingly well cross platform for desktop X86 and Android/ARM.
My email is in my profile if you have any questions.
C# can do that too, using Xamarin.
I used to complain about certain niggles in Xcode, but having used ADT, I shall never complain again. Comparatively, using Xcode is a joy.
The most likely reason to use the NDK is when you are using existing C(++) code, for instance from your iOS or desktop versions of your app. For me the biggest advantage is building the app for Win64, using rich tools and a high power testing platform and just run a different make and now I have an Android app.