How to integrate c code with java code

[Amit]

Hello friends,

Can u plz tell that if i want to write some piece of code for android
in c or c++, how can i integrate the code with java code.

Any help appreciated

Thanks
Amit

[Amit]

I want to know that if i write some piece of code in any languagge
may
be C or even Java,
how can i integrate it in android SDK. How can it be called like
other
android APIs.


For example, if i write some framework like video playback frame work
in any language,
how can it be integrated with android framework so that applications
can make use of it like other APIs.
Are there any specifications for such code to be written.


If it cant be done this way, can u tell me if there is a way possible
for me to integrate it with my local SDK
so that my applications can make use of it. Does eclipse provide any
help in integratiing such source code.


Any Help Appreciated


Thanks & Regards
Amit

[Jean-Baptiste Queru]

You could start by looking at an example, e.g.
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/os/StatFs.java;h=912bfdf4302b84ebae5a64656029d65b37a70fa3;hb=HEAD
and http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/jni/android_os_StatFs.cpp;h=c658aa587ec6264e42f6a6fc849db7dda5aff00e;hb=HEAD
but you'll find that (unless I'm mistaken) you're just going to be
using the familiar way to call between the two languages.

JBQ

[Amit]

Android supports JNI at application framework level.
For example, in platform/frameworks/base.git, Mediaplayer.java at:
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=media/java/android/media/MediaPlayer.java;h=b6064e1bb6b0f40f72fc1535b264f5c3fa190548;hb=HEAD
file has got some native function calls
And these native function calls must be implemented in either
libmedia_jni.so or media_jni.dll
but i'm unable to located either of the files in the source code. plz
tell me the path if they are present in the source code.

i found a c++ file android_media_MediaPlayer.cpp at:
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=media/jni/android_media_MediaPlayer.cpp;h=f9f3646f0c308bf19bb3c3af02fc0e0e4260afbd;hb=HEAD
that implements the corresponding native functions,
but coudnt find how it calls the actual c/c++ libraries. Also, it
includes files media/mediaplayer.h which i coudnt find.
This must be the file generated by java file using javah.

It also included files JNIHelp.h and android_runtime/AndroidRuntime.h
which are also untraceable.
Plz help me in this problem.

Thanks
Amit


On Dec 1, 7:21 pm, Jean-Baptiste Queru <j...@google.com> wrote:
> You could start by looking at an example, e.g.http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;...
> andhttp://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;...

> >> Amit- Hide quoted text -
>
> - Show quoted text -

[Phil HUXLEY]

Amit,

The following are some notes I’ve thrown together regarding adding a native
C/C++ library into Android and making it available through a Java class.

I am unsure if this is Google’s recommended way of doing things, but have
tried to ensure that I don’t contaminate the core namespace of the
Platform.

In particular with respect to the right approach to developing using
Eclipse and the java library.

The Android example I found most useful to look at was that of libdrm. This
is located under frameworks/base/media/libdrm. The source to the C part of
the JNI code is located under that directory in:

frameworks/base/media/libdrm/mobile1/src/jni/drm1_jni.c.

The Java classes associated with the C code are located under:
frameworks/base/media/java/android/drm/mobile1/*.java

It is helpful to look at these files and consider the following key things
that are needed:

A java library that contains classes which a) have declarations for
native methods and b) calls System.loadLibrary(“MyLibrary”) upon
initialisation. The mechanism that bridges between the Java and C/C++
domains is that of JNI – there is plenty of documentation about this
on the web. Note that care is needed at this interface because java
components do not necessarily have a straight-forward translation to
the C world (for example java arrays need to be locked while
accessing them as their memory is movable etc).

A shared library (for example) libMyNativeLibrary.so which contains a)
the native methods (relating to those methods declared as native in
the java classes) and a special function JNI_OnLoad. This function
gets invoked when the VM loads the shared library. In it you need to
register the native methods associated with the classes in the java
library.

I also had to add a line into the file
build/core/prelink-linux-arm.map that included my shared library. I’m
not clear on what this does, but I get a complaint when building if I
don’t have it.

A ‘jar’ file that contains the definition of the classes that can be
used when developing with the java library. When your java library is
built you should find a related ‘classes.jar’ file (created in
out/target/common/obj/JAVA_LIBRARIES/mylib_intermediates). You can
reference this file from an android project as an external jar such
that classes and methods etc are resolved correctly.

NOTE: At the moment, it seems that the Android SDK is not set up to
handle referencing ‘system’ libraries in this way. This means that
currently when you go to run the application, a run-time check will
fail because it ends up that there are multiple copies of the classes
involved (I believe one in the application and one in the image).
This throws out an error like: ‘Class resolved by unexpected DEX’.
Suggestions have been made that it may be possible to use and to link
the java stuff to avoid this. There are probably other approaches
though (see round about line 116 in dalvik/vm/oo/Resolve.c) – I’ve
disabled this test while playing, but that’s not a viable solution.
The real solution has got to be some way of generating all this stuff
so that a jar file can be referenced from an Android project.


The Application that uses this library must declare that it uses the
library by having a <uses-library> clause in its manifest.xml file
(open it up in the eclipse project and add something like:

<uses-library android:name=”com.mycompany.mylibrary”>
into the applications clause. Without this uses-library clause it
won’t work.

In the permissions.xml file (under frameworks/base/data/etc), you need
to have a declaration that links the name of the library (as above),
with the jar file that gets generated when a build is done – look at
the other entries in the file.

When an Android platform is built (assuming you are trying things out on
the emulator) you need to create a run configuration that points to
where your image (with the shared library and classes is located). To
do this you need to add options for –kernel, -system and –skindir
into your run configuration. I also add a logcat option to get
tracing specific to my library to pop out onto the console window.
For example, something like:

-system /Android/out/target/product/generic/
-kernel /Android/prebuilt/android-arm/kernel/kernel-qemu
-skindir /Android/development/emulator/skins
-logcat Mytag:D,*S

Directories and Structure.

I haven’t found any documentation about where you are meant to place things
in the source tree, but have had endless hours of fun guessing. In the end,
I created a directory just under the root of Android and placed my java
classes and shared library underneath it in separate directories (maintain
the relationship between the directory names and the package).

Both the shared library and the java classes have an associated Android.mk
file and each has a definition of LOCAL_MODULE which defines the name of
the shared library and jar files generated.

Once built you should find that your image will include the shared library
and java library. (You can see them using ‘adb shell’ when the emulator is
running).








Amit
<singhalamit85@gm
ail.com> To
Sent by: android-platform
android-platform@ <android-...@googlegroups.com>
googlegroups.com cc

Subject
02/12/2008 10:14 Re: How to integrate c code with
java code

Please respond to
android-platform@
googlegroups.com

ForwardSourceID:NT00004112

[blindfold]

Will use of JNI under Android be transparent to the developer in the
sense that one need not compile for various different CPU instruction
sets to create and distribute correspondingly different packages for
all different phone types (with different CPUs)? The latter would
complicate application maintenance and targeted distribution. With JIT
compilation as used on other mobile phone platforms, the CPU-dependent
compiler is of course on each individual phone, such that the
application developer need not worry much if at all about instruction
set dependencies, but it is not yet clear to me how this is foreseen
with the JNI approach (for running Android JNI-based apps on phones
featuring an ARM9, ARM11, x86, etc). Will there be a (client-side) C
compiler on each Android phone for generation of the native object
code to link to via JNI, or only a (cross) compiler on the developer's
computer? Sorry if this question was perhaps already addressed
elsewhere, in which case I would appreciate a pointer.

Thanks

On Dec 1, 3:21 pm, Jean-Baptiste Queru <j...@google.com> wrote:
> You could start by looking at an example, e.g.http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;...
> andhttp://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;...

[Jean-Baptiste Queru]

Talking about native code by definition is about targeting individual
CPUs (and possibly individual ABIs as well). If you prefer to write
code in a CPU-agnostic way and want the device to translate your code
aaccording to the local CPU, write on top of the virtual machine,
that's the exact reason why it exists.

JBQ

[blindfold]

> If you prefer to write code in a CPU-agnostic way

No that was not my point. The source code will still be plain standard
Android/Java and plain standard C with a standardized JNI interface.
No or negligible fragmentation there, and the writing part remains CPU-
agnostic. The problem lies in fragmentation of the subsequent
packaging and distribution: how does one prevent having to distribute
say 5 different packages (for 5 different CPUs) - but still for
exactly the same source code bundle. How does the user pick the
package that suits his phone without having to look through a list of
supported CPUs and selecting the one that is in his phone. That is
where things get a little messy and inconvenient for the user unless
something special is done to prevent this.

However, your reply suggests that no solution to the problem is
foreseen for Android, and we will see this packaging and distribution
fragmentation. Yet I could also imagine simply having a gcc compiler
on every phone which compiles the standard C parts at installation
time: that gives all the speed benefits at runtime while taking care
of CPU dependencies (different phone types will simply have different
gcc compilers on board). That avoids packaging and distribution
fragmentation, avoids JIT compilation, and does what JNI is mainly
intended for, namely giving a performance boost to relatively small
but CPU-intensive and hence performance-critical program parts.

Regards

On Dec 3, 2:49 pm, Jean-Baptiste Queru <j...@google.com> wrote:
> Talking about native code by definition is about targeting individual
> CPUs (and possibly individual ABIs as well). If you prefer to write
> code in a CPU-agnostic way and want the device to translate your code
> aaccording to the local CPU, write on top of the virtual machine,
> that's the exact reason why it exists.
>
> JBQ
>

[Jean-Baptiste Queru]

I was writing strictly from the point of view of actually compiling,
testing and debugging the code. The rest is actually easy:

-Nothing would prevent from creating "fat" packages.

-It'll be up to Market (and similar application-distribution systems)
to only present the user with choices that'll be compatible with their
device, exactly like platform API versions and add-on libraries need
to be handled.

Putting a compiler on a phone sounds like a horrible idea:

-Decent compilers are huge and slow when compared to the capabilities
of a phone.

-That'd require compilers for a variety of languages.

-That doesn't solve the issue for people who want to write assembly code.

-There are too many differences between the types of environments that
Android will run on to expect that writing code portable enough to run
across all those environments without first testing on each individual
target will be a practical solution for developers.

JBQ

[Mark Murphy]

blindfold wrote:
> The source code will still be plain standard
> Android/Java and plain standard C with a standardized JNI interface.

I am uncertain it is safe to assume that all code will comply with those
restrictions.

> How does the user pick the
> package that suits his phone without having to look through a list of
> supported CPUs and selecting the one that is in his phone.

For Android Market and similar sites (e.g., AndAppStore), the
device->market API would need to supply the phone model. The store could
map that to a CPU on the back-end and select the appropriate package.
The user need not realize there are multiple flavors of the application,
unless she has an unusual phone that is not in the phone->CPU map or
visits a store (or Web site) that isn't model-aware.

I'm not an embedded systems developer by trade, but one of the cardinal
rules seems to be: never require a device to do something that could
reasonably be achieved outside the device.

> Yet I could also imagine simply having a gcc compiler
> on every phone which compiles the standard C parts at installation
> time

Intriguing. GCC isn't svelte, though -- I'm seeing reports of 50MB for
an edition on Maemo.

What this does is take a developer headache (dealing with multiple CPUs)
and make it a device manufacturer headache (greater OS storage
requirement) and secondarily a core Android team headache (install-time
compilation, keeping GCC in sync with everything else).

That doesn't mean it's not a good trade-off. However, I don't know who
exactly is representing the interests of the device manufacturers on
this list, and only they can indicate how problematic it would be for
them to support that much additional OS space.

--
Mark Murphy (a Commons Guy)
http://commonsware.com
_The Busy Coder's Guide to Android Development_ Version 1.9 Published!

[blindfold]

Good points Mark.

> Intriguing. GCC isn't svelte, though -- I'm seeing reports of 50MB for
> an edition on Maemo.

gcc may be an unlucky example - I'm not even sure about ARM support,
and other compilers may have a much smaller memory footprint (Turbo C
3.0 for the x86 PC is just over 3MB and would easily fit on a G1, but
I did not check on standards compliance, and there is the Tiny C
compiler that is even much smaller and supposedly ANSI C compliant
http://en.wikipedia.org/wiki/Tiny_C_Compiler, and so on). These things
need to be sorted out, but at first glance it looks solvable. So don't
take my "gcc" reference literally but as a placeholder.

> For Android Market and similar sites (e.g., AndAppStore), the
> device->market API would need to supply the phone model. The store could
> map that to a CPU on the back-end and select the appropriate package.

Yes, that is a possible solution, although as a website owner I do not
like to be dependent on external distribution channels, so I would
have to add that same functionality to my website.

I guess the message from the Android Team is clear that putting a C
compiler on the phone is not on their JNI roadmap.

Regards

> Mark Murphy (a Commons Guy)http://commonsware.com

[blindfold]

> Putting a compiler on a phone sounds like a horrible idea:

Actually, Android seems prepared for supporting just that "horrible
idea":

http://code.google.com/android/reference/java/lang/Compiler.html

which is like a hybrid of JIT compilation with automatic profiling
(like one finds on Nokia phones) and the explicit partitioning into
Java and C required with JNI, but now with compilation (of Java
classes instead of C) on the phone. The term "Just In Time" here must
imply that compilation takes place on the phone, not on the
developer's PC. In fact I think this is the easiest - and upward
compatible - step towards full-fledged JIT compilation support,
avoiding platform dependencies in package distribution, avoiding the
complexity of reliable runtime profiling for fully automatic code
partitioning by requiring the developer's explicit Java partitioning,
and avoiding the need for "a variety of languages". I'm sure there is
a good case for JNI too, but it shows that the idea is not all that
horrible. BTW, Java and C are not that different that one could not
also have a "light" C compiler on the phone for (most, computational)
C code for use with JNI. What works here for Java/Android must largely
also work for C, and vice versa, except for down-to-the-metal hardware
or Linux dependencies.

Regards