The general underlying purpose of this blog is to help people (including me!) to get to better grips with the Android platform. In that spirit, let’s start a new series of posts that consider – in isolation – different parts of Android technology (terms and technologies that surface every now and then, but with their significance remaining somewhat submerged!)…
Which is a very round about way of saying ‘find out about things that sound important but about which I have no clue’!
First up is the “Dalvik virtual machine”, the open-source software originally created by one Dan Bornstein. This rather intimidating sounding phenomenon is the process virtual machine that runs in Google’s Android OS. Basically, it houses the Apps running on your smartphone or tablet, or set-top box come to that.
The Dalvik virtual machine
Wikipedia neatly summarises it thus:
Android uses the Dalvik virtual machine with just-in-time compilation to run Dalvik bytecode, which is usually translated from Java bytecode.
Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimised for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included “dx” tool.
Basically, the Dalvik virtual machine performs transformation of the application’s Dalvik bytecode into native instructions, so there would be platform-specific Dalvik virtual machines for each hardware platform running Android, be it from Intel, ARM, or TI. A developer’s compiler creates Dalvik bytecode, and a Dalvik virtual machine deciphers that bytecode.
Reflecting the Linux roots of Android’s design, separate user processes run – in the Dalvik VM – in relatively secure isolation from ‘core’ or kernel services, such as security, memory management, process management, and the network stack.
Here is what Google also has to say about .dex files:
Android programs are compiled into .dex (Dalvik Executable) files, which are in turn zipped into a single .apk file on the device. .dex files can be created by automatically translating compiled applications written in the Java programming language.
The Dalvik Debug Monitor Service (DDMS) is a key debugging utility that is integrated into the Eclipse IDE, the favoured development environment for Android apps.
Dalvik and Iceland
Why ‘Dalvik’? Bornstein named it after the fishing village of Dalvík in Eyjafjörður, Iceland, according to Wikipedia, whether as somewhere his ancestors lived or just a favoured place…
Read a post by Dan Bornstein on the Dalvik JIT » (source of the pic at the top)
You can view a larger version of the Android Architecture Diagram that is thumbnailed right.
If you want a lot more detailed low-level information, check out the Dalvik bytecode, Dex file format, and instruction formats – see a complete spec for the format in the Dalvik git repository or on the Dalvik Docs Mirror.
Note that underlying details can change, so you should always check these source documents for definitive data.
The move to the Android Runtime ART
Note that Google will be moving to a new Android Runtime system, ART. In Introducing ART, on source.android.com, Google writes:
ART is a new Android runtime being introduced experimentally in the 4.4 release. This is a preview of work in progress in KitKat that can be turned on in Settings > developer options. This is available for the purpose of obtaining early developer and partner feedback.
Important: Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications.
Most existing apps should just work when running with ART. However, some techniques that work on Dalvik do not work on ART. For information about the most important issues, see Verifying App Behavior on the Android Runtime (ART).