7 ms·

Android++: Native development and debugging extension for Visual Studio

70 points by uonyx 13y ago

dragontamer 13y ago
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/06/04/intel-is-inside-the-new-samsung-galaxy-tab-3-101-inch 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.
- jevinskie 13y ago
  You can ship multi-arch APK (with MIPS too).
- xamlhacker 13y ago
  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.
bdfh42 13y ago
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 13y ago
  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 13y ago
    Good point. For better or worse, iOS is native code, and you could potentially write C or C++ that targets both.
  - pjmlp 13y ago
    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_ 13y ago
  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 http://www.cocos2d-x.org/games/all?p=8&page=1
  - Pxtl 13y ago
    Yeah, nobody wants to have a GC pause just as they're about to do something tricky.
fredgrott 13y ago
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?
- Pxtl 13y ago
  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.
  - mattmanser 13y ago
    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.
- 13y ago
leobelle 13y ago
For C or C++ android development, what do people use on Mac? Xcode?
- jaegerpicker 13y ago
  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.
- mox1 13y ago
  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.
corysama 13y ago
This is a very cool project. Anything that improves on ndk-gdb is tremendously exciting to me. 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 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.
fidotron 13y ago
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.
- kevingadd 13y ago
  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.
  - acemarke 13y ago
    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-android-native-android-ui/ http://starkravingfinkle.org/blog/2011/11/firefox-for-androi... and http://www.mozilla.jp/static/docs/events/vision/2012/04-mark-finkle.pdf http://www.mozilla.jp/static/docs/events/vision/2012/04-mark... .
RayDonnelly 13y ago
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.

70 points by uonyx 13y ago

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/06/04/intel-is-inside-the-new-samsung-galaxy-tab-3-101-inch 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.

jevinskie 13y ago
You can ship multi-arch APK (with MIPS too).
xamlhacker 13y ago
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.

bdfh42 13y ago

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 13y ago
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 13y ago
  Good point. For better or worse, iOS is native code, and you could potentially write C or C++ that targets both.
- pjmlp 13y ago
  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_ 13y ago
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 http://www.cocos2d-x.org/games/all?p=8&page=1
- Pxtl 13y ago
  Yeah, nobody wants to have a GC pause just as they're about to do something tricky.

fredgrott 13y ago

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?

Pxtl 13y ago
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.
- mattmanser 13y ago
  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.
13y ago

leobelle 13y ago

For C or C++ android development, what do people use on Mac? Xcode?

jaegerpicker 13y ago
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.
mox1 13y ago
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.

corysama 13y ago

This is a very cool project. Anything that improves on ndk-gdb is tremendously exciting to me. 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 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.

fidotron 13y ago

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.

kevingadd 13y ago
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.
- acemarke 13y ago
  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-android-native-android-ui/ http://starkravingfinkle.org/blog/2011/11/firefox-for-androi... and http://www.mozilla.jp/static/docs/events/vision/2012/04-mark-finkle.pdf http://www.mozilla.jp/static/docs/events/vision/2012/04-mark... .

RayDonnelly 13y ago

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.