Android++: Native development and debugging extension for Visual Studio(android-plus-plus.com)
android-plus-plus.com
Android++: Native development and debugging extension for Visual Studio
http://android-plus-plus.com/
7 comments
This is certainly good for games and similar multimedia heavy type apps.
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.
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.
If by JavaScript you mean making a webview-based app with something like Cordova/PhoneGap, then that's not a great option either. Pre-4.4 WebView on android is notoriously bad, and things as trivial as smooth scrolling are a huge issue. The same app performs fine on iOS and on Android 4.4 which uses Chrome's engine, but unfortunately it will be a while before older versions go the way of IE6. I agree that C++ is not a solution for portable GUI apps either (although it works great for portable games since OpenGL ES runs on pretty much everything.)
https://crosswalk-project.org/ is a Chromium-based runtime that works on Android 4.0+
> if you're using C++ for portability for any sort of non-realtime needs you've lost your marbles
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.
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.
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.
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.
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.
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.
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.
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.
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++.
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++.
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.
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.
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.
It's my understanding that this counter-intuitive performance problem with Dalvik is what crippled the original UI for Android Firefox - they were using their native C++ UI stack (the one used on Windows, Mac and Linux) to implement the whole browser UI, but they found that in practice a UI stack written in Java running on Dalvik performed better because it wasn't subject to all the weird performance penalties from interacting with android frameworks.
I don't think that's entirely correct (yes, XKCD #386 applies):
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... .
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... .
This is intriguing - I had no idea that the Mozilla experience so closely mirrored my own.
The fun thing about Android is you can often spot when apps load the native code library since it generally leads to mysterious black screens during the loading of activities for exactly the kind of reasons mentioned there.
The fun thing about Android is you can often spot when apps load the native code library since it generally leads to mysterious black screens during the loading of activities for exactly the kind of reasons mentioned there.
I would point out to all the above commenters, that Chrome is still largely native code, with simple wrappers on iOS and Android. http://www.chromium.org/developers/design-documents/android-...
Yes, but this also goes some way to explaining my assertion that such apps are disproportionately large and slow to start - Chrome exhibits exactly that behaviour.
When they get closer to having the OS WebView actually updated via Chrome channels then it's conceivable that the apparent startup time will come down, and it wouldn't surprise me if this is one of the main reasons for it.
If you see this recent thread: https://groups.google.com/a/chromium.org/forum/#!topic/blink...
They even say this: "The web is quite far behind in mobile, which is why we're applying a greater amount of focus to solving the problems we have on mobile, even at the expense of nice-to-have features."
This is quite an admission, and at odds with a lot of their noise. It's also telling about their problems because Chrome suffers from a sort of death by a thousand cuts. On mobile to get the user experience people demand (they aren't wrong to be after 60fps performance as studies have shown mobile users are even pickier than desktop net users) you simply can't afford things like that anywhere, let alone right as the app starts up.
When they get closer to having the OS WebView actually updated via Chrome channels then it's conceivable that the apparent startup time will come down, and it wouldn't surprise me if this is one of the main reasons for it.
If you see this recent thread: https://groups.google.com/a/chromium.org/forum/#!topic/blink...
They even say this: "The web is quite far behind in mobile, which is why we're applying a greater amount of focus to solving the problems we have on mobile, even at the expense of nice-to-have features."
This is quite an admission, and at odds with a lot of their noise. It's also telling about their problems because Chrome suffers from a sort of death by a thousand cuts. On mobile to get the user experience people demand (they aren't wrong to be after 60fps performance as studies have shown mobile users are even pickier than desktop net users) you simply can't afford things like that anywhere, let alone right as the app starts up.
You seem to think that each of these posts is supporting what you claim, when it's doing nothing of the sort.
Firefox was slow because it had a very expensive abstraction layer that, while tolerable on a high power desktop, was just too much for what could be a low power mobile device. They didn't switch from C++ to Dalvik, they changed their GUI layers and how they initialize. This does nothing, at all, to support your claim about native apps being either slow to start or being large.
Nor does the Chrome bit. It's a large, full-featured browser. Further, on what is it slow to start?
Firefox was slow because it had a very expensive abstraction layer that, while tolerable on a high power desktop, was just too much for what could be a low power mobile device. They didn't switch from C++ to Dalvik, they changed their GUI layers and how they initialize. This does nothing, at all, to support your claim about native apps being either slow to start or being large.
Nor does the Chrome bit. It's a large, full-featured browser. Further, on what is it slow to start?
I am curious, what are the benefits of VS over other IDEs?
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?
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?
VS has amazingly good debugging tools. Other coding features seem to be prettymuch standard, like showing you arguments for a function you're calling and good autocomplete and refactoring and jumping around to declarations. It's got all the typical bells and whistles - all manner of GUI designers, Source-control integration, test-integration, code-review/commenting, etc, although they're very mature. I mean, it's obscenely featureful and the features are generally sensibly designed, so the sum is more than its parts there. The one place I really feel it actually shines is debugging.
That source control integration is definitely not 'mature'. It's terrible. Forgetting that TFS is just awful to begin, the integration in VS is lacklustre and based around very poorly thought out identi-lists and identi-tables that it's hard to extract any information out of. Simple things like getting a list of changed files in a build is several clicks and barely readable when you do find it. You get lost on what screen you're in cause they all look exactly the same. You're never sure exactly what you're committing and it also likes to throw some obscure warning which 90% of the time means nothing, 10% of the time is a repo or commit killer.
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.
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.
IntelliSense is the best C++ code completion/"jump to definition"/"find all callers" feature available on any platform. The Visual Studio debugger is the best C++ debugger I've used. That's pretty much it, but it's enough.
Code completion and jump to definition isn't unique to VS. Pretty much any modern IDE offers it. GDB is an extremely powerful debugging tool that has a feature set that is really hard to match. It just has an extremely step learning curve. I can't really see much of an advantage of this besides getting to use tools you already know, which no doubt is a huge advantage.
No other code completion tool for C++ comes close to what VS offers, especially in speed. GDB is "powerful" but its UI is no comparison to VS, and when I say that I don't mean "GUI is better than CLI", I mean GDB's UI sucks. And UI does matter.
Code completion and jump to definition isn't unique to VS
of course not. But that is not the point, instead the point is those tools in VS are better than anything else out there. Having used a bunch of them I tend to agree. Definitely usability-wise the debugging experience just beats everything else.
of course not. But that is not the point, instead the point is those tools in VS are better than anything else out there. Having used a bunch of them I tend to agree. Definitely usability-wise the debugging experience just beats everything else.
I tried many IDEs, I developed at lest one project in most of the common languages and I still have to find one IDE that get anywhere near VS. It is solid, with good extensions, tons of features but yet it's not scary and quite ugly like most of other IDEs. The only downside is that when you have 6 or more solutions open my computer starts to slow down.
Oh and has one of the best vim integrations.
Oh and has one of the best vim integrations.
At least one clear advantage is that Eclipse is horribly slow in debugging when compared to VS. I don't know how does IntelliJ compare to it because I haven't used that.
Eclipse (at least for Android, I don't know how the platform-specific plugins affect this) is painfully slow period. My workstation is not new, but it is a decent quad core and it does have 8GB of RAM... yet even with nothing but openbox, a browser, and a text editor to contend with, it still manages to bog and lag consistently.
With the rise of x86 Androids, is it really wise to start focusing on the NDK now?
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.
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.
As the other poster responded, NDK is not limited to ARM. NDK makes it (mostly) easy to write C++ and then compile it to multiple ISAs (x86, ARM and MIPS) and then ship all the binaries in the same APK. When the APK is installed and run on the device, the device automatically picks the appropriate binary files in the APK.
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.
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.
You can ship multi-arch APK (with MIPS too).
This is an interesting project for sure. WinGDB is quite similar.
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.
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.
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.
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.
They also say:
I recall the fireside android team chat one time (two years ago?) that went something like:
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>
Good point. For better or worse, iOS is native code, and you could potentially write C or C++ that targets both.
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.
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.
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
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
Yeah, nobody wants to have a GC pause just as they're about to do something tricky.
So maybe AAA studios shouldn't be using Unity. Oh wait...
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.
Ah you mean like the Witcher 2 for the XBox 360 where the C++ engine uses a GC?
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.
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 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.
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++ is the one language that can work on both iOS and Android (and Windows phone?)
C# can do that too, using Xamarin.
C# can do that too, using Xamarin.
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.
With Xamarin you must buy it, which may not be an option for hobby developers.
Xamarin does have a nice UI for working with Xcode/iOS, though I too fall on the cheap side of the fence. :)
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.
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.
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.
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.
I used to complain about certain niggles in Xcode, but having used ADT, I shall never complain again. Comparatively, using Xcode is a joy.
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.
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.
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!
It also has Clang now!
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.
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.
It is possible to make a substantially "NDK-only" app. Mainly for porting games.
For C or C++ android development, what do people use on Mac? Xcode?
I used Xcode or the command line flow with (cgdb, the ndk command line tools, and sublime text as the editor). Xcode did ok for editing, syntax highlighting, and compiling but I could never get the debugging working in it. If I could have got the debugging and project setup working Xcode would have been really good, as it was it was a pretty bad experince.
ADT is java and works on all platforms Eclipse works on. Additionally, the NDK (Native Developer Kit) is downloadable for Windows, Linux and Mac. I've personally used Android developer tools with native development on OSX, it works fine.
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.