An Oracle blog about Mobile Cloud Service

  • March 6, 2013

ADF Mobile: Avoiding the Android Emulator with AndroVM

Chris Muir
Product Manager

(Post edit 2nd July 2014: For users of Oracle's next generation ADF Mobile known as Oracle Mobile Application Framework (MAF), on the Android Emulator it now supports Intel's HAXM drivers which significantly speeds up the execution of the emulator. We highly recommend this as a way of speeding up your development experience.)

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 address>

...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 did crash 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.

One final note, remember, your company, such as Oracle, may have a policy restricting you from installing third party software which is not official approved. You should check before proceeding with this installation.

Join the discussion

Comments ( 6 )
  • Daniel Fages Wednesday, March 6, 2013

    Hi Chris,

    I lead the AndroVM project - thanks for your post on using it with ADF Mobile.

    If any of you have problems using AndroVM, the best way is to use the dedicated google group - https://groups.google.com/forum/?fromgroups#!forum/androvm

    Concerning the missing features when compared to the stock Android emulator, we're working on this - our goal is to have an optimal replacement tool to the stock emulator, with more features and more performance.

    If you think of any interesting features missing in the AndroVM project, feel free to make suggestion to the google group.

    Best regards,


  • Chris Muir Thursday, March 7, 2013

    I worthy note on the network from my colleague Angelo Santagata.

    If you disable the first network connection and then with the second network connection create a port forward as follows:

    Name: whatever

    Protocol: TCPIP

    Host IP: -null-

    Host Port: 5555

    Guest IP: -null-

    Guest Port: 5555

    ...this removes the need to setup any connections on your local network, and in fact removes the need for a local network at all.

    In addition you no longer have to issue the "adb connect <ip address>" command as adb will automatically connect to the emulator. You can test this by issuing "adb devices" right after starting the VM, and you should see the emulator listed as something like "emulator-5554". You can then issue an "adb install <.apk>" and this will install straight away. In turn if you issue an "adb install -r <apk file>" this will reinstall the application keeping any previous data.

    Thanks Angelo

  • Ibrahim Demir Sunday, March 10, 2013

    Hi Chris;

    With the hint from Angelo , I'm able to deploy the HR application to the AndroVM within the JDeveloper. It is really fast when compared with the Android Emulator.

    Thanks for the great post

  • Yossi Nakash Wednesday, March 27, 2013

    Hi Chris,

    Thanks, it worked Great - much faster than the Android Emulator.

    I also tried a couple of other things on androVM - I created apk file from JDeveloper, and installed it on the AndroVM, worked like a charm !



  • Otto Bertalan Friday, May 24, 2013

    Hi All

    Try BlueStacks player. Runs on Windows and Mac (in windows runs very fast (I have not tried it on Mac).


    adb connect



  • Chris Muir Friday, May 24, 2013

    Thanks Otto. I had tried Bluestacks, but discounted it because it was overly slow, at least on my Mac. So it appears as per your comment it's a viable option for PC, maybe not at this stage for the Mac. However it's early days, it's still a beta.


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.