If you've had a chance to use ADF Mobile since its release and you're developing for Android, you will have been unlucky to encounter a small issue with Google's Android Emulator, it's incredibly, painfully, excruciatingly slow. It really is an annoyance as the iOS Simulator on Macs runs lighting quick. Oh the woes of developing for the Android platform, who would of thought this was the developer friendly platform?! ;-)
Mind you the problem isn't particular to ADF Mobile, just a generic issue with Google's software which all Android programmers have to deal with. This means of course you can search for solutions on the internet, and between the hundreds if not thousands of posts detailing requests on "how do I make the Android Emulator faster" you will find the occasional very useful answer. The most common one is "test on an actual device". However there are some alternatives, of which one I've been recently exploring and I'd like to mention here in order to make ADF Mobile Android testing slightly less painful.
Before I do, I must clearly note this option is not supported by Oracle at all, and, via my testing it doesn't 100% work with all ADF Mobile's features. But given the woeful state of the Android Emulator it at least gives you an option to work with.
AndroVM is a project dedicated to providing a working Android VM client for VirtualBox. Of significance for ADF Mobile unlike other efforts such as Android-x86 project, AndroVM attempts to mimic the ARM architecture under the covers with an ARM instruction set translator called Houdini. Why is this important? If you can imagine Oracle has written a mini JVM for the iOS and Android platforms which sits above the hardware layer. If the underlying chip architectures are wrong, this is going to cause the JVM grief.Installing AndroVM is a fairly easy affair, you download and import the VirtualBox OVA file. Ensure to download an OVA with Houdini included. Beyond here it takes 14 seconds to boot to the Android home screen on my Mac. Take that with the 38 seconds it takes to boot the Android Emulator on the same machine even while hot restarting, that's a big difference.
The AndroVM documentation pages have plenty of useful installation notes which are worth checking out. One important point, the Escape key on your keyboard is mapped to the Android back button.
From here the most important bit to configure correctly is the VM network settings. At the time of writing the androVM-4.1.1_r6.1-20130222 release comes with two network settings, the first (eth0) is a null (disabled) connection, and the second (eth1) is a NAT connection to emulate a wifi connection. The documentation states you need to set the first connection as a "host only network" and attach it to a "DHCP-enabled network". For whatever reason I couldn't get this to work so instead I configured a "bridged network" as follows:
Note this connects to my Mac "en1: Wi-Fi (AirPort)" connection which in turn connects to my local router which serves an IP for the Android VM. If you decide to go this same path, you'll need to pick an appropriate connection on your local machine to bridge the network connection.
To use AndroVM from here, what we're going to do is use the Android SDK adb command line tool to manually deploy an Android .apk file generated by ADF Mobile to the VM. Before we can do this we need to know the IP address the VM has started with. You can obtain this by logging in, opening Apps then androVO Configuration which will show you the IP address top left:
If you can't see this it means you haven't configured the network settings on the VM correctly. You wont be able to proceed without this so take a step back and get that working correctly. There's an excellent explanation of the different VirtualBox network types here.
Once you know the IP of the VM, open a terminal window, cd to your Android sdk install directory then cd to platform-tools:
cd <sdk dir>/platform-tools
From we'll use adb to connect to the VM by issuing the following command to connect to the IP address we revealed a few steps ago:
adb connect <ip>
...and if you've set up the network connections properly you should hopefully see:
At this point you need to return to JDeveloper and generate the .apk package. As such we cannot deploy directly from JDeveloper at this stage (though you could easily setup an extension to do this), rather we'll manually deploy the .apk via adb into the VM. Upon generating the .apk make sure you understand where the file was generated as it will be used in the next command.
Returning to the terminal once the .apk has been successfully generated, you need to issue the following command in the terminal:
adb install <path to apk>/<apk file name>.apk
(Note it's worth reading the documentation on using adb, it's a very handy little utility)
In the example below you can see I've successfully installed the DeviceDemo sample application supplied with ADF Mobile:
Note that blindingly fast <2 second deployment time!
From here you're ready to test the application, and just like the regular emulator the application will be available from the Apps window:
And from there you can start the application, here's the Device Demo running, and it only took 3 seconds to start:
Now I've deliberately led us down the garden path here with the Device Demo, because it reveals limitations in the solution. The Android Emulator allows us to connect up PC services like the webcam so we can take pictures as if were using a real device. Via AndroVM we're not going to have the same facilities. So while it's great that we've massively cut the deployment times, it's not going to be suitable for all our needs.
Beyond this from my testing it seems to run most (not all) applications fine. I took all of the ADF Mobile sample applications (CompGallery, DeviceDemo, GestureDemo, HelloWorld, JavaDemo, LayoutDemo, LifecycleEvents, Navigation, PrefDemo, SkinningDemo, StockTracker) and they all appeared to work with some rudimentary testing. However the HR application didn't crashing at the beginning. I suspect this might be because it's the only application that uses the SQLite database though when I have time I'll need to investigate this further.
Be it as it may, this is not a supported platform for ADF Mobile so you'll need to live with its issues. However the speed benefits are I'm willing to bet enticing.
I'm going to leave the Comments for this blog post open. Please do not post any "it doesn't work" or "how do I get this to work" type comments as I will delete them, as I said it's not supported. However if you do happen to find a problem and solve it, it would be good if you could share it here.