State of Android/Juce on Modules Branch?


#1

Hi,

To cut a long story short, my hatred for All things Android has brought me full circle. Since my iOS experiments yesterday were very reasonable, I started looking at Android again to see if Juce might save me periodic Android utility development grief.

But I am a loss as to how to build/run today’s commit without crashing on the Emulator. I tried to minimize variables, I setup a new Android environment on a Mac, and put the NDK and SDK in the same paths (/SDKs) as Jules. I can open Eclipse, import a NDK sample, build, and run it.

But my two JUCE attempts end in heart ache.

Case 1: Used latest Introjucer to make a new project, added the Android Target, said to create a simple window. I disabled all the audio modules, cryptography, camera, and extended gui.

I built and ran in in XCode to make sure that I hadn’t missed any dependancies. All OK.

Next, I built it using “ant debug” from the Build/Android folder. The lib compiled, and the Java files were copied from modules to src/com, but, as I expected, no apk file was generated.

So I reverted to pre-build, opened Eclipse, selected New Project, from existing source, made the name JuProject, and pointed to the same folder.

Running this project as is results in a class not found error, which is what I would expect. So, again, I reverted, created a project from existing, checked that the target was Google API 7 (which I did install, as well as 4.03), right clicked on the project, and added Native API support, checking the NDK path, and setting the lib to “libjuce_jni.so”.

This compiles fully in Eclipse, packages the library, and runs, only to explode on the emulator (either running 4.03 or 2.1). The exception is class not found, thrown from a call to method.invokeNative, which seemed to suggest to me that the library was being invoked. But I simply could not get Eclipse to do source breakpoints or even stack source display in the lib.

So, as I’ve done with JUCE before, I ran to Case 2, JUCEDemo. I basically repeated the steps above, basically deleting the Android folder and using git reset --hard to revert each time.

Open New Project in Eclipse, use existing source, right click and add native support, using libjuce_jni.so for the library name get’s the farthest, that is, it builds without error and appears to package up. But, again, it explodes in execution, both in 4.03 and 2.1, but after sending some system information to the log, which seems to strongly suggest that JuceDemo at least started.

I hate hitting up others for build stuff, but I did notice that with JUCEDemo, I had to manually create a “com” folder under “src” for the JuceAppActivity class to get copied from Modules/Core. It seems that Introjucer created that empty folder structure automatically with my new project. That made me wonder what, precisely, the state of Android was on tip of the Modules branch.

I guess what I’m looking for is the commit on this branch that someone can confirm JUCEDemo builds and runs, and what SDK/NDK it links with, and what platform runs on the Emulator. Since I have to manually tweak the directory structure to get JUCE Demo to work now, I either have operator error, or am in an indeterminate state.

I’d also bee curious if anyone has gotten source Native debugging working under Eclipse with Mac. I have gotten it to work on Windows for another project, but I had no luck here.

Thanks in advance for any help!

PS. Eclipse is SDK 3.7.1 and SDK and NDK are latest as of today.


#2

It just figures, after an exasperating afternoon of Android tool hell, and then airing my problems here, I got it to work.

There is a tiny problem that seems real, that is, the absence of the “com” folder under src in the Android Build of JuceDemo. The required helper class files do not get copied by the make without it. But I found that early on. Otherwise bdbe7d3f010 JuceDemo builds and runs under Android just fine.

For reasons that I still don’t understand, JuceAppActivity was not getting instantiated, so when the native call came from it, things exploded. I threw Jules’ ReadMe advice out the window and built up the project from scratch, basically mimicing what IntroJucer does. And it just worked.

So, I deleted everything and repeated the steps I wrote above, and it still just worked… I’m happy to admit that I’m an idiot, but I’d sure like to know what I changed and how.

I also seem to have figured out why NDK-GDB wouldn’t attach, I don’t seem to have a working PackageManager on this emulator install. Once I hacked that, it would attach. JUCE still seems symbol stripped, but I’m sure that is another brain fart on my part. I’ll look at that tomorrow. Right now I have to crawl off in shame…


#3

The whole android development process is dreadful! If you spot anything that you think I could automate better, please let me know, the whole process involves such a complicated bag of assorted scripts that it’s hard to keep track of what’s going on in there.


#4

One thing that does seem to be an issue, at least with this Eclipse install, is the links for the two Java files (src/com/juce).

The links don’t exist until after the build.xml has been run, and Eclipse (at least this 3.7.1 install) has trouble resolving the files indirectly. I had manually copied the files last night building up by hand, which seems to have been my mystery fix.

I don’t have time today, but I’m going to dig deeper into the underlying toolset. It is maddening that Eclipse doesn’t reliably deal with clean and dirty. I’ll give you whatever info I can find.

One issue it seems you will eventually be dealing with is package id. It looks to me like the package must be com.juce to satisfy the class constant used in the jni helper in JUCE. But package identifiers must be unique for apps to coexist on the device.

I don’t seem to have any trouble hacking around it, but ultimately it seems like a job for Introjucer. The user provided bundle identifier sets to location of the java files, and perhaps goes into the ProjectInfo defines, so that the JNI helper can construct the location of the java helper class at compile time.

But I haven’t really given it much thought (I generally push Android out of my mind after every encounter). If you have a different longer term Android/Introjucer plan, I’d like to hear about it. Android is a periodic thorn for me. With the new modules approach, the app size is a bit more reasonable, and JUCE might really be the ticket for us for certain utilities.

Sorry about the long initial post, I’m not used to being stumped for the better part of a day on build issues and got frazzled.