“Alien Dalvik” ?

It is going to be interesting to find out exactly how this works.

Despite the name it cannot simply be a standalone Dalvik port. After all, all Dalvik can do is run Dexes. In fact the following would seem to suggest that it might not involve a Dalvik VM at all

Alien Dalvik enables the majority of Android applications to run unmodified, allowing application store owners to quickly kick start Android application store services by simply repackaging Android Package (APK) files.

Its not clear why you would want to mess with the APKs unless you wanted to do something else at the same time, especially if they are signed, but who knows ?

Presumably unmodified in this context refers to the source code ?

To run the majority of Android applications unmodified it must implement all the standard Java APIs and the Android APIs used by those applications some how. If the source code does not need to be modified then all those classes and methods that are referenced need to be in the runtime.

Implementing a large part of what is approximately Java 5 plus a large part of some version of the Android APIs (which version is of course another problem) is not exactly trivial given that many of the Android API methods are actually native methods, or call native methods almost immediately, and they often use Android platform specific features, for example, Skia and Surfaceflinger to name but two. In fact it is quite difficult to see how it can run the majority of Android applications unmodified unless it actually contains what amounts to a largish chunk of, not to put to fine a point on it, Android.

Which leads on to the question of where this chunk might live ? Presumably it is not per downloaded application, so the chunk must (?) be pre-installed on the device, and it is this that the device manufacturer will be licensing (?).

There is also the question of memory footprint. Android relies quite heavily on code sharing via the Zygote mechanism to keep its memory footprint down. It is possible to achieve the same effect using the standard fork()/exec() mechanism if your VM has been written with that in mind, although this is one of the techniques that Oracle argues they have a patent on. This is not necessarily a problem if the underlying VM technology is licensed from Oracle, which it might be in this case.

Then there is the question of native code. Presumably Android applications that use native code need not apply ?

And then there is security. Android applications are sand-boxed on the basis of UIDs and permissions are enforced on the basis of GIDs. If the host OS does not have these or their equivalents then there is a problem. Equally if host OS native applications are not themselves sand-boxed, even if Android applications cannot get out of their sand-boxes, everything else on the platform may be able to get into them

And if there are host OS native applications as well then how do they co-exist without some form of integration at the window manager (or equivalent) level ?

As I say it will be interesting to find out how it actually works

---

Copyright (c) 2011 By Simon Lewis. All Rights Reserved.

A Standalone Android Runtime: Running HelloWorld The Hard Way

Whichever way HelloWorld gets launched there is a point at which the runtime will start to execute the code in the HelloWorld package HelloWorld.apk. Which is a problem. HelloWorld.apk is a standard Android package built using the Android development tools so what is in it, as you might expect, is a classes.dex file, which is nice if you are the Dalvik VM but not so great if you are another kind of JVM that does not talk Dalvik bytecode, and ours does not.

So why not put the class files in the package when its being built and use them ? Where’s the fun in that ? The contents of classes.dex started out as some class files, so lets turn it back into the class files on demand !

To do this we need a specialized ClassLoader which is pretty simple, in this case at least, a Dex loader, likewise, and a DVM to JVM bytecode compiler, which is a bit trickier. Fortunately the HelloWorld application is doing nothing much at all so there are not a large number or variety of instructions to compile.

Loading the Dex file and compiling the code back into JVM bytecode on-the-fly is not necessarily how you would solve this problem for real but it will work in this case.

Compiling is not the most visual of activities so instead here is the trace from the compiler which is invoked by the ClassLoader when the first class in the HelloWorld application is accessed by the runtime. To make life simpler at this point we load the entire Dex file and compile everything in sight, which is not a lot as you can see. The compiler is printing each DVM instruction as it compiles it.

Process[25001]: 
Process[25001]: Class standalone/helloworld/HelloWorldActivity
Process[25001]: 
Process[25001]: compiling <init>
Process[25001]: 
Process[25001]: invoke-direct Landroid/app/Activity; <init> ()V
Process[25001]: return-void
Process[25001]: 
Process[25001]: compiling onCreate
Process[25001]: 
Process[25001]: invoke-super Landroid/app/Activity; onCreate (Landroid/os/Bundle;)V
Process[25001]: const #+2130903040
Process[25001]: invoke-virtual Lstandalone/helloworld/HelloWorldActivity; setContentView (I)V
Process[25001]: return-void
Process[25001]: 
Process[25001]: 
Process[25001]: 
Process[25001]: Class standalone/helloworld/R$attr
Process[25001]: 
Process[25001]: compiling <init>
Process[25001]: 
Process[25001]: invoke-direct Ljava/lang/Object; <init> ()V
Process[25001]: return-void
Process[25001]: 
Process[25001]: 
Process[25001]: 
Process[25001]: Class standalone/helloworld/R$drawable
Process[25001]: 
Process[25001]: compiling <init>
Process[25001]: 
Process[25001]: invoke-direct Ljava/lang/Object; <init> ()V
Process[25001]: return-void
Process[25001]: 
Process[25001]: 
Process[25001]: 
Process[25001]: Class standalone/helloworld/R$layout
Process[25001]: 
Process[25001]: compiling <init>
Process[25001]: 
Process[25001]: invoke-direct Ljava/lang/Object; <init> ()V
Process[25001]: return-void
Process[25001]: 
Process[25001]: 
Process[25001]: 
Process[25001]: Class standalone/helloworld/R$string
Process[25001]: 
Process[25001]: compiling <init>
Process[25001]: 
Process[25001]: invoke-direct Ljava/lang/Object; <init> ()V
Process[25001]: return-void
Process[25001]: 
Process[25001]: 
Process[25001]: 
Process[25001]: Class standalone/helloworld/R
Process[25001]: 
Process[25001]: compiling <init>
Process[25001]: 
Process[25001]: invoke-direct Ljava/lang/Object; <init> ()V
Process[25001]: return-void

---

Copyright (c) 2009 By Simon Lewis. All Rights Reserved.

A Standalone Android Runtime, Or Look Ma No Dalvik !

Having experimented with getting the Dalvik VM to run independently of the Android OS and application runtime, I thought I would try and turn the problem on its head and see whether it was possible to get the Android application runtime to start-up and run a simple HelloWorld app independently of the Android OS and the Dalvik VM, using a standard Java environment, to begin with a desktop JSE, but possibly CDC/whatever later on. To make it more interesting I wanted to do it without running any native (non-Java) code, at least initially. After all the Android runtime is written in Java so hard could it be ?

---

Copyright (c) 2009 By Simon Lewis, All Rights Reserved.

Workaround

It looks as though the problem with mmap() is that the filesystem doesn’t support making mmap()ed files writable which prevents Dalvik as currently implemented from optimizing its Dex file, which prevents it from starting. A workaround for this is to provide Dalvik with an optimized Dex file we prepared earlier. If you do then you get this

Dalvik Running Standalone (but not quite working) on an N800

A screenshot of Dalvik running in an xterm on an N800

The error (which has scrolled off the top) seems to be a failed call to mmap()

Dalvik Running Standalone On MacOSX

When the source for Google’s Dalvik Java VM became available as part of the Android open source release I thought I would see whether it was possible to build and run it standalone, i.e not as part of Android.

The answer is yes, and here’s a shot of it running in the debugger under Xcode on MacOSX to prove it

Unfortunately the canonical HelloWorld application on its own doesn’t make for particularly interesting viewing

With verbose logging on the output is certainly a lot more voluminous.

Here’s the debugger window scrolled to different positions to show all of it