tags:

views:

1237

answers:

3

I want to incorporate small, lean and mean C-based parser into my Android project. I've done JNI programming in the past but not any type of native (C) development on Android. My plan is to compile C lib into SO and create JNI wrapper around it which I'm going to use in my app. Is this how it can/should be done? Second and most important question - how can I include .so into my APK? Where would it go?

+1  A: 

use Android NDK
Download n docs Android NDK 1.6

This will save you from writing JNI layer for lib and also will install the app in the lib folder of your app data folder.

bhatt4982
Can you comment on "not writing JNI layer"? I need to use the C lib methods from my Java code are you saying that NDK would automatically create a wrapper for me?
DroidIn.net
Yes, it would. All you have to do is use "native" keyword for functions which are in your library. It has some pretty simple samples with it too.
bhatt4982
+1  A: 

Someone said that JNI in android sucks : http://www.koushikdutta.com/2009/01/jni-in-android-and-foreword-of-why-jni.html

Forrest
A: 

Depending on how much data you pass and how often I seriously doubt a Java/JNI/C would perform faster than a native java implementation.

Passing anything other than a "Java Int" to a "C long" invokes the JNI data conversion routines which are anything but lean and mean.

So unless your JNI routine fits the pattern:

  • Pass small amount of data.
  • Do lots and lots of work in C.
  • Pass small result set back.

You will be considerably slower than a native java implementation. If you stick with the basic "C" like java operations (+,-,*,==,>) using the "native" data types (int, char, String) and avoid the fancy libraries Java will perform nearly as fast as C.

The remaining bug-bear of java performance is the time taken to fire up the JVM and get everything going, but as you are starting off from a Java program this is a non issue.

The other reason for "slow" java performance is people insist on unnecessary factories, containers, xml beans etc. etc. where plain, simple methods would do the job better.

James Anderson