As many Android developers know the Android NDK is used to cross-compile native (C/C++) code to run in Android programs. Unfortunately, because it uses JNI we’re limited to a C-style call interface. Tools like SWIG can be used to automatically generate wrappers for existing code including C++ classes. In this post I’ll provide an introduction to native backed objects in Java, which are objects whose implementation/resources are primarily implemented in a native language. I won’t be using SWIG since it might muddle everything a bit because of what it takes to get it to wrap standard library classes on the NDK.
What are we trying to accomplish? Our goal here is to have the ability to write Java code that operates on normal Java objects, but underneath all of the “magic” is happening in C/C++ land. There are two main use cases for this: speed-ups from using faster native code for memory intensive/processor intensive operations, and for leveraging existing code bases into a new Android project. Especially in the second case, native backed objects give you the ability to write UI code for a new Android project that uses your existing C++ classes as the main base of functionality; we simply create “wrapper” classes that can be used in Java land the same way you’ve been using them in C++ land, but now have the added benefit of being directly inter-operable with the Android framework. Continue reading “An introduction to native backed objects with the Android NDK”
At work we’ve been developing new Android hardware, and as such I’ve been porting a lot of our existing C/C++ code to Android using the NDK, a collection of GNU build tools (gcc, objcopy, etc.) and associated scripts to aid the development of native C/C++ code on Android. One of our projects is nearly 1000 source files, and therefore can be a bit of a headache to debug. For a while I’ve had a problem where this project would crash when built in release mode, but work fine when built for debug. Unable to spend the time to figure out what was going on, I’d simply been using the debug build of the code. However recently the performance implications were too great and I needed to get to the bottom of what was going on. Interestingly enough, the issue wasn’t uninitialized memory (as is usually the case with debug/release inconsistencies) but rather a bug in GCC 4.4.3’s optimization of memcpy. Continue reading “Over-aggressive GCC optimization can cause SIGBUS crash when using memcpy with the Android NDK”
Continue reading “Progressive drawing of simple SVGs on the HTML5 Canvas element”