Android tool that might be of interest


#1

http://www.crystax.net/android/ndk-r4.php

It’s not the fancy C++ to Java bytecode through LLVM that you initially thought about, but it does support C++ exception and RTTI so by writing delegated rendering in Java that’s calling JNI’s Juce based renderer, you could probably get a basic port working, don’t you think ?

Here’s some code to actually call a Java method from C++ (might need a bunch of these to port Juce, through)

void
Java_net_sourceforge_projects_roadmap_RoadMap_DoubleJniTest(JNIEnv* env,
jobject thiz, char *s)
{
        jclass          cls;
        jmethodID       mid;
        int             i;
        jstring         js;

        cls = (*env)->FindClass(env,
"net/sourceforge/projects/roadmap/RoadMap");
        if (cls == 0)
                return;

        mid = (*env)->GetMethodID(env, cls, "AddDummyButton", "(I)I");
        if (mid == 0)
                return;
        i = (*env)->CallIntMethod(env, thiz, mid, 5);

        js = (*env)->NewStringUTF(env, "yow");

        mid = (*env)->GetMethodID(env, cls, "AddButton",
"(Ljava/lang/String;)V");
        if (mid == 0)
                return;
        (*env)->CallVoidMethod(env, thiz, mid, js);

}

        public void AddButton(String name) {
                Button doit = new Button(thiz);
                doit.setText(name);
                buttons.addView(doit);
        }

        public int AddDummyButton(int a) {
                Button doit = new Button(thiz);
                buttons.addView(doit);
                return 123;
        } 

#2

The main problem was never that the c++ compiler couldn’t handle the code, it was that the NDK doesn’t give you access to all the APIs - for lots of basic system stuff, you need to go via the java classes.


#3

Well, I edited my initial post but too late.
Yes you actually need to call the Java’s version of the API, but it’s not unfeasible (check the code above).
It’s quite similar for the Java code calling C++ code.

I’m not sure you need to port everything, but for me, doing the basic 2D rendering stuff, sound and input source might be enough, at first ?
Ideally, in the native/ folder, you could put some template java files, calling the internal Juce stuff (à la Jucer), so that this “stub/wrapper” is compiled in Android projects, and users don’t have to deal with Java at all.
If they want to hack the template java files, they can, and they have access to the “Android API”.


#4

Oh, and since the Android’s C library is very limited, and C++ library inexistant, and new Juce’s GIT use a lot of STL, the former link is still of interest, in that case.


#5

This might be interesting to study:
http://code.google.com/p/kwaak3/


#6

I wish I had time to experiment with all this! I imagine it’s probably quite messy however it’s done, but it’s hard to judge what the best plan would be without trying some things out.


#7

Hi Jules!

The easiest approach is to use the crystax SDK (http://smartctl.net/android/ndk-r4.php), which allows you to use STL, Exceptions etc.
All very cool!

Needless to say, it’d be very cool if Juce ever got ported to Android. :slight_smile:

Pete


#8

Pete, that modified ndk has the same issues as the base ndk, I.e. there are a ton of api’s that you can only access from java…


#9

Hi cpr!

Yes, for sure. The solution is to call JNI adaptor functions, that call-back into the Java code to “get platform-specific things done” such as blit operations etc.
This is the approach I’ve been following for my second port of Mixtikl to Android.

(The first port - completed but not released - used the Airplay SDK from Ideaworks… that port is shelved due to various limitations in Airplay)

The thing about Crystax is that it allows C++ to use STL and Exceptions, which are pretty critical and not impressive omissions from Google in the first place in their NDK. :slight_smile:

I’d be interested to hear if you have any other thoughts on this. A Juce port for Android would, of course, be great!!

Best wishes,

Pete


#10

Their defence (!) might be :

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions
and
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Run-Time_Type_Information__RTTI_

:slight_smile:

I recently had to remove much of thr RTTI stuff in my audio library code to get the core of the library to work on Android. It was also a pain having to use the Java-side audio i/o when it’s probably doing the same operations at the hardware end back to C! That was a about a week before Android 2.3 came out - I haven’t had to time to look whether the availability of OpenSL in 2.3 is a better solution but I suspect it is…


#11

Quite - but their position doesn’t make it easy to port-in 3rd party code. :slight_smile:
Thank goodness for Crystax! :smiley: