How I Fought the Android NDK and NetBeans 6.8

In this post I want to share a bit the son of difficult mistakes - experience. You can’t tell otherwise, because some compilation errors, builds, etc. ate a lot of time. Not every time I got to the bottom of the reasons, I wanted to get a working math as quickly as possible. But somehow, I managed to find or read the right solution. Therefore, I just want to draw the attention of those who will go the same way to some nuances. Perhaps it will save you some time. In the end I will give an example of the application for which all this was needed. The picture from the title is a screen of the application.
And so, I had the following task. I wrote an application for Android, which turned out to be very demanding on resources. “Mathematics” (I mean working with containers, calculations, etc.) took a lot of time. For comparison, a console application in pure C ++ counted the task within 3 seconds. While the Android application on java, running on the emulator, the same thing counted 2.5 minutes. So I decided to bring the algorithmic part to C ++. I also want to note that I didn’t want to install Eclipse at all, so I struggled with what it was - NetBeans 6.8. So suppose you already have an SDK, NDK, and NetBeans and go ahead.

Problem 1

In the examples from the NDK archive, the source code is presented in “C”. If you want to use “C ++” and write your code in * .cpp / * .h - do not forget to replace the function calls of the JNIEnv object of the form (*env)->GetIntArrayElements(pixels, 0) with env->GetIntArrayElements(pixels, 0)

Problem 2

Compiling C ++ code in * .so. I put Cygwin for these needs. When installing it, do not forget to choose among the packages offered - make, by default it is not set. In order not to copy-paste the configuration of Cygwin and an indication of where to put your C ++ code - just give a link . There, everything is described in sufficient detail and the main thing is all in one place, which is not unimportant.
')

Problem 3

Compile and run apk on the emulator. It looks like NetBeans 6.8 has serious problems with deploying and running applications with so-libraries on the emulator. I was helped only by manual assembly (manual launch of ant compilation) and manual download of the application on the emulator. It should be noted that after the application compiled in this way is loaded onto the emulator, if there is no need to change (recompile and re-upload) the NetBeans so-library normally compiles the main part of apk, uploads it to the emulator and runs in both debug and release modes. Therefore, it turns out a tense situation. It is necessary to debug and lay out the native part separately (with a large number of gestures), and then in the usual mode to debug the java-part (interface).
The sequence of commands when compiling via ant is:
1. "android update project --target --path path / to / your / project /"
2. “ant debug” or “ant release”
3. After that, in the bin folder of the project there will be application assemblies and you can start downloading the application to the adb-e install bin / Application.apk emulator. The emulator should be running by this time.

Once again, these actions are needed only when debugging native code in order to compile it with the interface part and download it to the emulator. After that, there is no need to go beyond NetBeans to debug the java-interface part of the application. Why it happens this way, can it be done somehow differently - I do not know, therefore it will be interesting to hear comments from the guru.

UPD: The performance of the application with native code has increased 10 times. If, by experimenting with different containers, the calculation of the test problem on the Java code was reduced to ~ 100s, then using the native code with the STL, it is considered to be ~ 7s.

application

Well, in conclusion, a few words about the application for which it was all necessary.
This is a small paint editor for Android PaintUp that can build complex gradient fills. Back at the university for a similar task, we came up with one smart algorithm, which as it turned out quite skillfully copes with color gradients. And it became interesting to implement it on a mobile platform.
The result was a drawing box, which can make a pretty and not always predictable picture by several color strokes.
Description of the application on the android market here , below are a few examples (some with source code) and qr-code for installation.