With my AUv recording out of the way, I’ve been starting to think more seriously about my AU sessions, over the last few days. The “big one” (with 100+ registered attendees and counting) is about moving code from a desktop application to the cloud, and will basically summarise the process I followed in my “cloud & mobile” series of earlier in the year. Which means I’ll go through the process of pulling some code out of a desktop-based application and placing it behind a web-service, before calling the service from a variety of platforms/environments (AutoCAD via .NET, iOS, Android, WinRT, Unity 3D and WebGL).
Pretty much all of these should be easily demoable during the session, but I was a bit concerned about the Android piece: until now I’ve only been able to execute the Android version of my Apollonian Viewer application on my Kindle Fire device, which doesn’t have an easy way of connecting to a projector. So I set out with the intention of getting the app working on my desktop (whether inside Windows or OS X), so that I wouldn’t even have to worry about cables or connectivity issues.
There were two main routes open to me for this. The first (which I should probably point out didn’t work for my particular situation, before anyone starts trying it without reading to the end) was presented by Philippe Leefsma, over on ADN’s Cloud & Mobile DevBlog: to install a Virtual Machine based on Android-x86, a x86 port of the Android OS. It took my a while to track down a usable “generic” ISO image: they seem not to have posted one for the latest version, 4.0-RC2 – all the versions posted for download are targeting specific hardware configurations – so I ended up having to take a chance on an unstable nightly build posted here.
When launched, it started a fancy new Android session directly on my desktop:
Running netcfg inside a terminal window on the device told me its IP address, which I could then use to connect to it via adb. From there it was straightforward to debug on the device, connecting to it from my project in Eclipse. This also installed the app, so that can we can also see it in our list when not debugging:
The reason it didn’t work – and I half knew this, but wanted to go through the process of setting this up, anyway – was that OpenGL ES 2.0 is not supported by Android-x86, at least not right now.
Which left the second option… to get the Android emulator to run OpenGL ES 2.0. The good news is that since earlier this year this has been possible, it seems. It was a bit fiddly to set up – this page helped a lot – but it took me some time to actually get a GPU-enabled emulator instance running OpenGL ES 2.0.
Here are the settings I used – I found I couldn’t set the “GPU emulation” hardware setting on an existing emulator, for some reason, but creating a new virtual device solved that:
One of the major issues was that even if it’s possible to get the emulator set as GPU-enabled the emulator reports itself as not supporting OpenGL ES 2.0. So in your code you need to find a way to suppress the standard check again this property when you’re testing with an emulator.
Thankfully Rajawali, the 3D framework I’m using for my application, added this capability some time ago. It was a simple matter to change the application to set the protected checkOpenGLVersion boolean to false, which allowed the application to execute and me to find the remaining issues to fix (which basically comprised the fact that for performance reasons 3D primitives – such as Spheres, the only one my application creates – no longer have a default material attached, so we have to create one).
And so I could run the application inside an OpenGL ES 2.0-capable emulator. Yay!
Here’s the base environment:
Here are the applications:
And here are the launch screens for the Apollonian Viewer:
And finally we see our spheres, even if the lighting looks like it needs some adjustment:
Now that I have at least the basics working, I’ll probably get back to working on the core material. At some point I may take the time to see what’s up with the lighting – perhaps my lights need adjustment or I’m using the wrong material – but for now I’m just happy to see the app working inside an emulator.