Any experience with Android NDK?

I’m specifically interested in how portable it is between various phones. We have an application with some computation heavy code we’d like to share between Android and iPhone. If we could write it in C, we’d have a single code-base, but if the NDK only supports a subset of the processors that phone manufacturers are creating, or if we have to recompile for each processor, that’s not a workable solution.

Thanks for any experiences with it.

  • Gallery items overlapping (bleed in)
  • How to get a count of list items from Listview?
  • What are alternative ways to launch my app?
  • PercentRelativeLayout inside ScrollView
  • PercentRelativeLayout is more Performant?
  • PorterduffXfermode: Clear a section of a bitmap
  • Related posts:

    Android: the GC doesn't respect SoftReferences?
    Start Activity from Adobe AIR native extension for Android
    Converting MIDI file to raw audio using a software synth
    Android, How can I rotate an arrow (image) around a fixed point?
    Android - startActivityForResult outside an Activity?
    How to play multiple(max four in my case) .m3u8 video streaming in single activity in android?
  • How does the Android L contacts app collapse its toolbar?
  • Use Handler To Post In To UI Thread
  • Turn (rotate)marker position based on direction over the route
  • How to rectify NullPointerException in v4.DrawerLayout?
  • Renaming app in Android Market during upgrade
  • Android- How to send data from activity to service?
  • 4 Solutions collect form web for “Any experience with Android NDK?”

    On the subject of whether all Android (version 1.5+) phones will support the output of the current NDK:

    All I can say is there’s nothing in the documentation to suggest otherwise (unless perhaps if you read an implication in “this release supports the ARMv5TE instruction set”), and I follow Android news fairly closely and haven’t heard of any Android phones being released using a non-ARM architecture (though some people hacked together a build for EeePC). Looking at the Android source, there are traces of only one other platform, x86. As for the future plans of Google and the OHA? You’d have to ask them. They recently announced some developer days, but probably all the spots are gone now (the first one is today). I registered pretty early for the London day (17th) so if I get in I’ll try to get an answer there (I’m keen to know definitively too).

    I am not very familiar w/ Iphone development, but if you look on the android ndk page, under the development tools section, it lists the guaranteed headers available in the platform, so if the iphone supports these functions, or you can create interfaces between your code and the native libraries on both platforms than I don’t see why it wouldn’t work.

    The NDK is basically an implementation of the Java Native Interface for Android. It gives you GCC 4.2.1 (the full set of tools as far as I can tell) with target arm-eabi. Whether the resulting code would run on an iPhone or other devices I don’t know; I’ve never coded for the iPhone. Here is what file has to say about something I built with the NDK so perhaps you can compare:

    libpuzzles.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped

    (strip is included; I just haven’t run it here.) Here is gcc -v or g++ -v (they’re identical):

    Using built-in specs.

    Target: arm-eabi

    Configured with: /opt/digit/android/git/android-ndk/out/arm-eabi-4.2.1/toolchain/src/gcc-4.2.1/configure –prefix=/opt/digit/android/git/android-ndk/build/prebuilt/linux-x86/arm-eabi-4.2.1 –target=arm-eabi –host=x86_64-unknown-linux-gnu –build=x86_64-unknown-linux-gnu –enable-languages=c,c++ –disable-libssp –enable-threads –disable-nls –disable-libmudflap –disable-libgomp –disable-libstdc__-v3 –disable-sjlj-exceptions –disable-shared –with-float=soft –with-fpu=vfp –with-arch=armv5te –enable-target-optspace –with-abi=aapcs –disable-nls –prefix=/opt/digit/android/git/android-ndk/build/prebuilt/linux-x86/arm-eabi-4.2.1 –with-sysroot=/opt/digit/android/git/android-ndk/build/platforms/cupcake/arch-arm –program-transform-name=s,^,arm-eabi-,

    Thread model: single

    gcc version 4.2.1

    Assuming the code will run, managing this at the API level is a separate and interesting issue. Android will only let you call native code via the JNI API. I’m not familiar with the iPhone approach, but I know it’s not Java so I’d guess it’s more like standard dynamic linking or dlopen()? What I mean is, you would have to either make your JNI functions (e.g. Java_com_example_Foo_YourMethod(JNI_Env*, jobject, ...) cope with being called from something that isn’t a JVM (have your iPhone code fake a JNI_Env for example?) or, much less horribly, start by providing a native API suitable for iPhone and then include a JNI wrapper, which non-JNI platforms can safely ignore, which I gather is a common approach for this sort of thing. Hope that helps.

    I have had a nice experience writing cross-bread JNI/C app with framebuffer processing in NDK and rendering in JAVA.

    Pitty, its an android-only solution

    Android Babe is a Google Android Fan, All about Android Phones, Android Wear, Android Dev and Android Games Apps and so on.