Can I run run an android application as a standalone desktop application without an emulator?

Question

Is it possible to develop an android application aimed at mobile devices and also use the same code to execute on windows, linux or osx as a standalone java desktop application without using an emulator? I.e. to have the look and feel of a conventional java application running standalone?

Guide

I remember this from a while ago: arstechnica.com/open-source/news/2009/05/… Havnt seen any progress since though – Palaearctic

Answer 1

Android uses a custom UI framework, which doesn't run on the desktop. So, the short answer is no.

Longer answer:

Despite the above, you'll still be able to re-use some non-UI code between the two. Any code that doesn't call android.* will probably port over.

You also could write an abstraction layer that hides the details of the UI toolkit.

Finally, there are also some third-party application development frameworks which work across multiple platforms. The one that springs immediately to mind is Appcelerator's Titanium, but there's others out there as well. You might have some luck with these.

Pedicle

Answer 2

Android applications run on the Dalvik Virtual Vachine which a custom virtual machine (VM) which is not directly compatible with a standard Java VM.

As far as I am aware the only implementations of the Dalvik VM are on Android Devices and the Emulator.

Obviously, Android applications are written in Java so there is nothing stopping you sharing some code between an Android Application and Java Desktop application but that will probably have to be the "business logic" part. It's going to be difficult to make them look the same as the Android Classes haven't been ported to the Java VM and there's no implementation of AWT or Swing for Android.

So you might be able to create your own ListModel class containing data and then display it using a ListView on Android and a JList on the desktop, so you'll have the data but the displays will look different.

Onerous

Answer 3

Well, to do this is have the write a standard abstraction layer for the UI and Android specific APIs. Basically hide away all Android and Desktop specific calls behind interfaces.

This shouldn't be a very big problem since there's such a big overlap between Android SDK and the JDK.

Also, for things like XML parsing, network you can just use the classes that work on both.

Other than this I don't think there's any other approach that 'automatically' make your Android code run as a Java Desktop application.

Endless

Answer 4

The Skorpios project allows you to run OpenGL applications on both the desktop and Android using a single codebase.

There are some minimal examples. Here is the common code for those.

To run the common code on the desktop, pass a Game instance to a DesktopGLView. I use this class to run the tests, just pass the test class' simple name as a command line argument. Eg, "FontTest".

To run the common code on Android, pass a Game instance to an AndroidGLView, which is an android.view.SurfaceView that you can put in your android.app.Activity. Often you will want an Activity that just displays your game, in which case you can just pass the Game instance to a GameActivity instead of AndroidGLView. If you just want to run the test apps on an Android phone, you can just deploy the skorpios-android-test project to your phone.

Skorpios is pretty slick and it works well. Development speed is dramatically increased through the use of Java's HotSwap on the desktop since Android deploy times are often 60+ seconds. Develop on the desktop and after you make some real progress, run your app on Android and it just works. FWIW, I have some related projects that also support both the desktop and Android for client/server networking with TCP/UDP and another with HTTP/servlets/Google App Engine.

However, Skorpios is still early in its life. I'm the author and have been distracted with other things lately. So far it has many basic OpenGL functions. Supporting new functions is very easy (just add them to GL, DesktopGL and AndroidGL) and I have been adding them as needed.

I intend the project to act as an abstraction layer for OpenGL, but also for non-OpenGL desktop/Android features commonly used in games. Here are some examples that are currently implemented:

• Preferences persists a HashMap to disk on the desktop and uses android.content.SharedPreferences on Android.

• Database provides simple access to SQLite on Android and is currently a no-op for the desktop.

• Device provides access to Android vibration and is currently a no-op on the desktop.

• ResourceLoader provides access to files, preferences, and databases on each platform.

Embolism