Welcome to Android!

#1

Ok, I’ve created a new forum here for Android topics, and have just committed a version that (hopefully!) includes what you’ll need to start playing with Android.

The whole Android development experience is not exactly as slick as iOS. And that’s putting it politely. I’ve added a few helpful tips to the juce readme doc in the juce/docs/ folder of the source tree, but if you’re going to try android coding, be prepared for a lot of tedious faffing about (and that’s before you even get as far as using Juce!)

I’ve not even considered worrying about whether it’ll work on Windows yet, and everything I’ve done has been with the mac version of the SDK. I’m pretty sure it’ll also work fine on linux, and if there are any brave cygwin adventurers who want to try it, I’d be interested to hear how you get on. It may need a few tweaks, but presumably not too much.

The juce demo now contains an android build, which you’ll probably need to edit and re-save using the Introjucer to set up your SDK and NDK paths correctly. Please make sure you’ve already jumped through all the hoops involved in setting up and running some of the Android NDK demo projects before attempting a juce build!

I’m still working on support for features (e.g. I’ve not added audio support yet), so don’t expect to be able to pop out a fully-functional app immediately, but there’s enough there to start exploring.

#2

yay! :slight_smile:

#3

Woo-hoo! :smiley:

#4

You’d deserve a statue, somewhere in London.

#5

I, for one, will be lobying Boris about a sensible suggestion for Fourth Plinth

#6

great work Jules!

#7

great stuff!

one thing…

In the Introjucer “android exporter” project the “Android sdk Path” is “…/android-sdk-mac_86” should be “/android-sdk-mac_x86” with the “x”…, or at least that’s what my un-archived sdk folder was named.

builds fine here.

#8

If they have wi-fi access I could just sit on the plinth with my laptop and work there…

Ah thanks, looks like I must have typed it wrong when I installed it and then copied the typo into the codebase… Will sort that out.

Great that it seems to be compiling without too much hassle! Has anyone tried it on a real device yet? I’ve only been testing with the dreadful emulator so far, it’d be interesting to hear if it actually runs fast on a real machine.

#9

So I’ve got a successful build using ant, here’s the output;

[code]Buildfile: build.xml
[setup] Android SDK Tools Revision 10
[setup] Project Target: Android 2.3.1
[setup] API level: 9
[setup]
[setup] ------------------
[setup] Resolving library dependencies:
[setup] No library dependencies.
[setup]
[setup] ------------------
[setup]
[setup] WARNING: No minSdkVersion value set. Application will install on all Android versions.
[setup]
[setup] Importing rules file: tools/ant/main_rules.xml

debug:
[exec] Invalid attribute name:
[exec] package
[exec] Compile++ thumb : juce_jni <= MainWindow.cpp
[exec] Compile++ thumb : juce_jni <= Main.cpp
[exec] Compile++ thumb : juce_jni <= JuceLibraryCode1.cpp
[exec] Compile++ thumb : juce_jni <= JuceLibraryCode2.cpp
[exec] Compile++ thumb : juce_jni <= JuceLibraryCode3.cpp
[exec] Compile++ thumb : juce_jni <= JuceLibraryCode4.cpp
[exec] Prebuilt : libstdc++.a <= /sources/cxx-stl/gnu-libstdc++/libs/armeabi/
[exec] SharedLibrary : libjuce_jni.so
[exec] Install : libjuce_jni.so => libs/armeabi/libjuce_jni.so

BUILD SUCCESSFUL
Total time: 3 minutes 25 seconds[/code]

So far so good, I hope we’re on the same page here…

Now for the Eclipse “debug and run”;
Eclipse complains about the “default=“help”” target not existing in the project, deleted that property from the build.xml file… got it running in the simulator now! This all took longer than I expected to be honest, I read your doc on Android, so was prepared. At first I had no luck, kinda went back and forth, for a couple of hours with no success and almost gave up, but decided to start clean and fresh and got it all working.

Will try on device tomorrow, and report back, hopefully building onto a device isn’t to painful.

BTW, the ndk name has a “b” on the end of it “android-ndk-r5b”; but keeping up with sdk names should be up to the user… just need a message somewhere that mentions to look out for sdk/ndk names;

Like I said before, this is all superb! Being able to build an app for the Desktop, an iOS device, and and Android device is very big, and has endless potential, at least for me.

Thanks Jules

#10

Thanks!

I think I must have unzipped the SDKs differently to the way you guys did it - I seemed to end up with different names for both. But as you say, the user’s going to have to set them correctly for their system anyway.

I guess that should be ‘debug’ then… (have to admit that I didn’t really understand the ant script I was copying from!)

#11

Congrats Jules… what’s next… Commodore 64?

#12

Got a very basic test app going, just want to see what’s involved, editing code building/re-building on the simulator etc… I noticed in your doc that you mention Eclipse picking up the native changes but not re-packaging the app, I’m experiencing that too, and it’s a little annoying. I’m not familiar with Ant but found that there’s a “touch” task, maybe putting it in the debug target, something like ;

#13

No problem, I can still remember some of the 6512 assembly language op-codes that I used to write back in 1984… Even 25 years later, I still know that ‘169’ is LDA, and I think ‘96’ is RET…

[quote=“aiit”] I’m not familiar with Ant but found that there’s a “touch” task, maybe putting it in the debug target, something like ;

Possibly, though we probably don’t want to touch it every time… There’s probably a way to get it to touch the java file only when the library is changed, but my ant knowledge is almost zero - I’m hoping someone who’s done some ant development will be able to suggest a better way!

#14

I’m surprised you can type so efficiently, wrapped in your anorak :slight_smile:

After Nokia’s recent changes, Windows Phone, surely! - For then {picks canine with pinky} [color=#FFBF00]JUCE[/color] will DOMINATE THE WORLD!
A-ha-ha-ha-ha. Hahahahhahhaaah.[size=150] hahahhahaahahhahaahahhahaahahhahaahahhahaahahahaah[/size]
{Sorry, Jules. }

I still haven’t managed toget anything of the default Android (let alone Juce) to build under Cygwin, but I’ve been battling other stuff. (I don’t have disk space for Eclipse - so I’ll be using vanilla bash CLI tools. Smoke me a kipper.) I’ll let you know if I learn anyhing .

#15

I’ve used Introjucer to create Android build files for juce. I was able to build shared lib nicely, but when I tried to build static lib…it created 70 megs for release version. Is there a way to make static lib smaller in footprint? I don’t need all the gui stuff and practically I want to use juce as static lib inside my android C++ projects.

#16

Hmm…since we’re on the subject, I think that one of the early sound drivers for the Apple II+ looked like this:

]CALL -151

*302: AC 01 03 AE 01 03 A9 04 20 A8 FC AD 30 C0 E8 D0 FD 88 D0 EF CE 00 03 D0 E7 60

]POKE 768, 180 (FREQUENCY)

]POKE 769, 10 (DURATION)

]CALL 770

This will likely still work on an Apple II+ emulator.

#17

I don’t understand what you mean about a static lib? The only way I’m planning on supporting android is by a straightforward build where all your app code and the juce code goes into the shared lib. If you’re trying to do some other kind of off-piste build, then I’m afraid you’re on your own.

(But there’s nothing surprising about a 70 meg static library anyway - the unused code gets removed later at the link stage)

#18

Thought I should join in and congratulate Jules on this work, before I totally forget to. :mrgreen:

We’re planning on porting Mixtikl, Noatikl and LIptikl to Android through Juce. All thanks to Jules!

Pete

#19

It is not possible to build JuceDemo on Windows(XP) with current Android.mk due to maximum path/filename limits

But it is possible with the following changes:

  • Add to Adroid.mk
    LOCAL_C_INCLUDES :=
    …/…/…/amalgamation
    …/…/…/…/…/amalgamation\
  • Make a corresponding replace in JuceLibraryCodexx.cpp like
    //#include “…/…/…/amalgamation/juce_amalgamated1.cpp”
    #include “juce_amalgamated1.cpp”

I am sure these changes will prevent the project from building on other platforms. So keep it in mind or use conditional compilation directives

Anyway i am happy to know that the excelent Juce library is not ignoring this popular (but yet uncomfortable for a developer) platform

#20

Thanks! I’m trying to avoid worrying about building it on Windows just yet, as it was bad enough getting an Android development environment set up on *nix, I can’t imagine how horrible it is to try to use it with cygwin! Thanks for the tip though, I’m sure it’ll come in handy when I finally have to try to use it on Windows myself!