Coming from Windows Mobile native programming, the first thing that I checked before jumping into Android is, naturally, NDK. Fast forward to today, after many months of playing with Android NDK; I can say, now
, it is, indeed, fun to work with. I am trying to compile a small list of pitfalls that I believe you should pay attention to if you want to try this digital journey:
UTF16 was not supported for NDK development targeting platform below Gingerbread. Android JString is UTF8, you need to adjust every string if you are using Unicode UTF16 in your C++ source. My solution is to wrap all GetStringUTFChars with a UTF8 /UTF16 converter.
w_char is 4 bytes long. So any w_char * will give you garbage if you are lucky and crash your program if you do not change it. So walk the bytes to get your w_char * exact content.
3. Heap memory
There is no heap memory limit for a native application but don't abuse it. Java environment of Android 1.6 has 16MB limit, Android 2.x with HDPI has about 24 MB and Honeycomb has 48 MB. If you use too much of heap memory, Android starts to kill background processes and your user won't be happy: after using your application the system will be sluggish as the Android OS needs to start almost everything all over again. My solution is to make a call to Android Dalvik for functions with heap memory calls and let the OS defines the limit. The downside of this is that once memory usage reaches below the threshold of the available memory for an application, Android will kill your application without any warning. Well, under such a limitation, this should be a better way out than the other evil trap. HoneyComb is, indeed, fantastic. It comes with 48 MB heap memory limit, there is a lot of porting we can do in native code. I am working on some applications targeting HoneyComb using much of its more advanced features. Just to remind anyone who might want to scream fragmentation, get an ice cream to cool down; it is not fragmentation, it calls taking advantage of the horsepower available, hit the gas pedal, and zoom! or xoom
4. NDK tools
If you use Cygwin, download the latest version, it saves you hours in compilation time! Up to previous version of NDK tools, compiling C++ sources with many sub folders take hours (Windows 7, I720, 6G RAM), making debugging next to impossible for a big project.
5. Clean up your JNI local reference call rigorously
There is a limit to local references in JNI, you get this error: "ReferenceTable overflow (max=512)..." if you open too many local references. You need to clean it up in every local reference call, it piles up pretty fast. Don't try making it a global reference, as many suggestions you might read throughout the Internet, it only makes the situation even worse in some case, so just do it, clean it up, you are in C++, right?
Your application will crash once reference table overflows.
The above issues are some of the major issues I believe most native developer will face. Native programming for Android is not that hard once you have overcome these issues, it is better than Windows Mobile in many ways.