[bdfh42]

Interesting - but to quote from the Android developer website:

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.

[shadowmint]

They also say:

     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++.

Which continues to annoy me even now.

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>

That's certainly how I feel about it.

[mtdewcmu]

Good point. For better or worse, iOS is native code, and you could potentially write C or C++ that targets both.

[pjmlp]

Yeah, right.

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.

[djh_]

Don't forget games, the vast majority of popular games are likely running native code.

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:

http://www.cocos2d-x.org/games/all?p=8&page=1

[Pxtl]

Yeah, nobody wants to have a GC pause just as they're about to do something tricky.

[pjmlp]

So maybe AAA studios shouldn't be using Unity. Oh wait...

[corresation]

The overwhelming bulk of a Unity game on Android runs in purely native code (the Unity shared library). Of course the game orchestration and such runs in a managed runtime (mono), but the garbage created by simple orchestration/management running in a GC is minuscule compared to the garbage created by an entire game engine running in a GC.

[pjmlp]

Ah you mean like the Witcher 2 for the XBox 360 where the C++ engine uses a GC?

[melling]

What is like working with the NDK? C++ is the one language that can work on both iOS and Android (and Windows phone?)

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.

[NickPollard]

I find the NDK fine to work with - but I'm writing a game which is entirely C plus some embedded Lua/Moonscript.

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.

[Maarten88]

> C++ is the one language that can work on both iOS and Android (and Windows phone?)

C# can do that too, using Xamarin.

[pjmlp]

C++'s benefit is that it is common to all SDKs.

With Xamarin you must buy it, which may not be an option for hobby developers.

[lstamour]

Xamarin does have a nice UI for working with Xcode/iOS, though I too fall on the cheap side of the fence. :)

[pjmlp]

I have played around with all three, Java, C++, C#.

For business I would surely advise Xamarin, as their prices are quite reasonable.

But if you are just hacking some stuff every now and then, it might not be worth it.

And on that case, there is also the possibility to compile Java to native code in iOS (RoboVM) or use any other language that either has an AOT compiler, or has a compiler available that compiles via C.

It is always a matter how much time vs money, one wants to invest.

[jaegerpicker]

Pretty horrible. The gdb debugger is a pain in the ass to setup, there is no really good ndk based IDE, most of the UI and important API classes either aren't available or are vastly more complex to use, You still have to use java- if for nothing else to load and start the c/c++ code running, and JNI is a absolute pig of a technology for interfaces with other code. As a mobile dev working on iOS, Android, and Win Phone who occasionally needs the native performance of c I really wish it was better.

[djh_]

Having worked with the NDK in Android Developer Tools (Google's Eclipse Fork), it's pretty painful. It takes a long time to get the environment set up and working (somewhat) nicely. You have to get a plugin to debug via ADT, I used the ARM DS-5 debugger. It works, but it's not a good user experience.

I used to complain about certain niggles in Xcode, but having used ADT, I shall never complain again. Comparatively, using Xcode is a joy.

[mox1]

I used the Android NDK extensively for an app I wrote recently. The main reasons were for cross compatibility (future iOS port) and because a 3rd party library I needed was written in C.

If your new to the world of C/C++..then maybe its painful, but for me it was easy to get up and running. They use the GCC toolchain behind the scenes, with gdb as the debugger.

The NDK exists as a download for windows,OSX and Linux. I developed exclusively on OSX (10.8) (Using the android develop toolkit (aka ADT) which is basically a re-skinned Eclipse) and then enabled "ADB over IP" on my Nexus 4.

After a bit of setup (like adb connect 'local ip' ) the Android version of gdb (ndk-gdb) on the mac just "sees" your phone, finds the process and automatically connects.

If / when a crash would happen (and it happend a lot :) ) you get a stack trace, code line numbers, etc.

It might not be as simple as the GUI Xcode world, but it certainly works.

I've also got remote core dumps for my app, using Google's Breakpad. When the app crashes natively it uploads a core dump to my server, where I can examine what happened. Here as well you get full stack dumps, line #'s, etc.

[jevinskie]

As far as a cross-toolchain goes, the NDK is quite nice. For the most part, it Just Works for compiling code. The multitude of STLs and complicated (behind the scenes) Makefile system can be annoying. However, the Makefile system is very simple for common needs. Debugging can be a pain, yes. Google is very diligent about releasing updates to fix bugs.

It also has Clang now!

[corresation]

That is largely unfortunate dogma.

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.

[Zigurd]

It is possible to make a substantially "NDK-only" app. Mainly for porting games.