Thomas Snyder

Cpr E 308 Section E

Final Project Paper

Android Runtimes
Since its unveiling in 2007, Googles Android operating system has been based on the Linux kernel at its
core. However, simply using a Linux kernel isnt everything Android devices need to fully work and operate the
various uses they have. In order to run applications on Android devices a runtime compiler containing a process
virtual machine is needed. For a while now, the name of that runtime has been Dalvik. Now, with the introduction of
Android 4.4 Kit Kat, Google has announced the experimental use of a new runtime called ART or Android
RunTime. Both Android runtimes provide much of the same user-end functionality but the methods for providing
this functionality differs.
To understand why a difference between ART and Dalvik may be important, an understanding of the
service or function they provide must be clear. To understand that, a brief understanding of how Android works in
general is required. Figure 1 shows the Android system architecture and the levels of interaction throughout the
system. Applications, seen at the top of Figure 1, are the interfaces users interact with and provide input and output
(Brady, Patrick). These different applications are handled by the application framework. This framework handles the
applications somewhat indirectly and the user isnt really aware of what its doing. Its where views and
notifications are handled as well as phone services like GPS
and cellular calls. Beneath that, there is a collection of libraries
both custom and standard. These act as any libraries would in
any other sort of system. Next to the libraries is the component
in question, the Android Runtime. The runtime is where
bytecode is converted into machine code by the virtual machine
in order to be used with hardware and the Linux kernel. Lastly,
the Linux kernel; which is relatively typical of a Linux system

Figure 1 - Android System Architecture

and handles the drivers and hardware of the Android devices.

The Android runtime contains the ART and Dalvik virtual machines being compared. Both compile
machine code by interpreting bytecode and intermediate language such as Java class and jar files. The most common
source of code needing to be compiled comes from the applications users interact with on the device. Resulting
machine code from these compilations will end up being mostly the same, for a specific device, whether it was

compiled using ART or Dalvik. However, other specific similarities between the two runtime systems are scarce;
many aspects of the two are different.
The Dalvik virtual machine itself is unique; its essentially a custom version of a Java Virtual Machine
using a custom library based off of the Apache Harmony Java implementation. This custom virtual machine was
designed with certain hardware constraints in mind. It was designed to have low memory requirements as many
Android hardware at the time of its creation had very limited amounts of RAM. This is why the Dalvik virtual
machine uses a register based architecture instead of the stack based method of standard Java virtual machines.
Stack based machines often use more instructions in order to load data onto the stack which consequently takes up
more space. Register based virtual machines, like Dalvik, use bigger instructions to store the source and destination
registers meaning fewer instructions and less space used. The Dalvik virtual machine also allows the Linux kernel
to handle lower level aspects such as threading and low-level memory management. ART works similarly although
with a few key differences.
Main differences between the runtimes include device storage used, memory used, and most importantly
time of compilation. There are also several other smaller differences that will be explained too. Both ART and
Dalvik have their own tradeoffs for each main category as well as differences potentially noticeable by users of the
Android device. These differences are also very subject to change as the ART variant has only appeared recently
(September 2013) and is still in the process of being fully implemented; Dalvik is still the default runtime although
that is expected to change with the release of the next version of Android.
Dalvik has a few aspects that make it slightly less straight forward than ART. Dalvik uses .dex files as the
files to be compiled into the machine code used to interact with hardware. The .dex format is a Dalvik executable
file readable by the Dalvik virtual machine. The source of these .dex files comes from the Java files developers
write to create their applications. Java code written for the apps is first compiled
into bytecode by a Java compiler and this bytecode is then recompiled into a
Dalvik readable format the .dex file. Instructions normally intended for a Java
virtual machine also have to be converted to Dalvik compatible instructions. The
.dex file is similar to a Java jar file in the sense that it can contain several class
files. All of this conversion and recompilation is done by a tool called dx. When
the Android APK (application package file) is compiled on the development

Figure 2 - DEX Files

machine the .dex files are included. A simple visual representation of the relation between the different file types
can be seen in Figure 2 (Dalvik, the Virtual Machine of Android).
ART works surprisingly similar to the system of virtual machine-specific file types. Instead of .dex files,
ART appears to use .oat file types. These .oat files will eventually work in much the same way as the .dex files by
creating machine code from bytecode derived from applications Java code. Its not yet clear whether the .oat
format is completely new or just a new format for Dalvik executable code. Either way, the .dex files created during
APK compilation and used by Dalvik are made useless under ART. To help with the transition into the new .oat
format, Google has made official commits to the Android repository containing a dex2oat file. This file contains
methods to convert previously compiled .dex files into ART compatible .oat files without developers having to do
anything. Right now, because ART is still experimental, applications are still compiled containing the .dex files and
the dex2oat allows ART to use the same application compilation without much issue. However, the methods for
converting from Dalvik bytecode to ART Dalvik has not been completely optimized causing applications to not
always work under ART. In the future, APK compilation may include both .dex and .oat files while the transition to
ART is made.
An important aspect of the .dex files is their ability to be optimized. This brings rise to the use of odexed
and de-odexed applications and ROMs. Odexed applications have been optimized and de-odexed applications have
not. Optimizing applications basically means to pre-compile parts of the application that wont change on a given
instance of opening said application. Android device manufacturers often include odexed applications in their
ROMs because then they can optimize the application specifically for their device. This is because they know
exactly what hardware will be used and hopefully how to best use it. Utilization of odexed applications speeds up
the use of the applications with Dalvik because there is less bytecode to compile into machine code. Obviously
speed is a good benefit to device users; but, there are a few downsides to odexed applications. Firstly, they take up
slightly more space than their de-odexed counterparts; the pre-compiled code needs to be stored somewhere.
Second, odexed applications cant be re-themed or re-skinned; something some users like to do if they dont like the
look of an application. Either way, Dalviks maturity and ability to have applications well-optimized definitely
helps its performance (McGee, Jimmy).
As of right now, ART doesnt have the equivalent of odexed files for its .oat files. This is because of the
main difference between ART and Dalvik: time of compilation. The Dalvik runtime uses Just-In-Time (JIT)

compilation and the ART runtime uses Ahead-Of-Time (AOT) compilation. Differences between the time of
compilation account for the potential of a large improvement in performance with ART and therefore the reason it
has been introduced. However, the tradeoffs arent as simple as more performance.
Dalvik, as mentioned before, was designed during a time when Android device hardware was very limited
in storage capacity and system memory. The limitations in hardware caused Androids creators to use JIT
scheduling for compiling the apps. In Dalviks JIT implementation, apps are stored in the .dex files on the device
and when an application is prompted to be opened these .dex files are compiled into the machine code needed by
hardware; also known as native code. This method of constantly re-compiling applications every time they are
opened is relatively costly and causes applications to open slower than they could. Odexed applications obviously
excel here because every time they are opened there is less to be compiled. Each application requires its own
instance of the Dalvik virtual machine when being run. Luckily, the Dalvik virtual machine is efficient allowing for
multiple instances of the virtual machine to be open at a time providing multi-tasking abilities.
ART has todays technology in mind when handling the compilation of applications into native machine
code. Ahead of time means all applications are converted from .oat bytecode into native machine code when apps
are installed instead of every time they are needed. All of the native machine code needed for the application to run
on the device is permanently stored somewhere. This means applications are generally able to open fast on first
click because no compilation of bytecode has to happen between when the application is clicked and when it opens.
ARTs ahead of time scheduling sounds like its a much better option than Dalvik but it isnt that simple.
Each runtime has pros and cons it just depends which tradeoffs are worth switching from Dalvik to ART.
The main objective of ART is to increase a few things; battery life and user-noticeable performance. Dalviks
attractive aspects include stability, maturity, and lower hardware requirements. Storing the pre-compiled machine
code has the down side of using more storage space under ART. Dalvik beats ART with space efficiency because of
this. The importance of this tradeoff is debatable because of the space available on todays Android devices is much
more than it was when Dalvik was developed. Currently, users can expect applications running on ART to take
about 10% - 20% more space on average than they would using Dalvik.
Due to applications only needing to be compiled to machine code once, at installation, with ART there is
less stress on the CPU. There is a tradeoff between longer times to initially install an application on a device for
reduced future compilation time every time the application is prompted. This aids the noticeability of the speed at

which applications open; arguably the most noticeable performance benefit of ART. A simple comparison of the
performance of ART versus Dalvik to quick sort an integer array can be seen in Figure 3 (Shah, Sanket). ART is
clearly faster when running an application that needs to calculate a quick sort; although, it may be a relatively
contrived example. A popular Android blog, Android Police, has run thorough tests comparing benchmark scores
between identical devices running ART and Dalvik. The assortment of benchmarks tests show that CPU intensive
tasks often perform better on ART while Dalvik is better at memory optimization (Toombs, Cody).

Figure 3 - ART vs Dalvik Integer Array Quick Sort

A reduction in time the system spends compiling code allows for more idle time. In theory, more idle time
should mean a better battery life as the CPU isnt drawing as much power. Obviously, ART should therefore have
better battery life on average than Dalvik. However, Android Police has also done a thorough comparison of battery
life between ART and Dalvik and found inconclusive results. They recorded only a 2% - 4% difference (favoring
ART) in battery usage between the two runtimes which isnt exactly substantial.
Although tests comparing the runtimes dont seem exceptionally promising for ART there are a few things
to consider. Dalvik is much more mature than ART; its been around with JIT since 2010. Its had much longer to
be optimized and figured out by developers and device manufactures to benefit performance and battery life. ART is
still only experimental and nowhere near the level of performance it can potentially reach. Applications are still
being converted from .dex files to .oat files to fit ART; in the future, applications will be compiled directly to the
.oat format. Direct compilation will surely improve the quality and stability of the applications running on ART.

When ART becomes the standard, manufactures will be able to create odexed-like versions of .oat files for their
applications and ROMs which will both save space and improve performance.
To name either the ART runtime or Dalvik runtime better than the other at this time would be unfair. Both
runtimes work with the same general functionality only with different compilation scheduling methods. As time
goes on, Google will make ART standard and it will become more and more optimized; effectively becoming better
than Dalvik. For now, ARTs slight performance increase gives hope for what the Android runtime could become in
the future. Either way, ART will be a step forward for performance, battery life, and overall smoothness of Android
devices.

Bibliography
Brady, Patrick. "Anatomy & Physiology of an Android." Anatomy & Physiology of an Android - 2008 Google I/O
Session Videos and Slides. Google I/O, n.d. Web. 25 Apr. 2014.
"Dalvik Technical Information." Android Developers. Google, n.d. Web. 22 Apr. 2014.
"Dalvik, the Virtual Machine of Android." The Dalvik Virtual Machine for Android. N.p., n.d. Web. 25 Apr. 2014.
McGee, Jimmy. "Android Basics 101: Understanding ART, the Android Runtime XDA Developer TV." Xdadevelopers. XDA, 12 Feb. 2014. Web. 25 Apr. 2014.
Shah, Sanket. "ART Runtime for Kitkat 4.4 Explained." Word Press. N.p., n.d. Web. 25 Apr. 2014.
Toombs, Cody. "Meet ART, Part 2: Benchmarks - Performance Won't Blow You Away Today, But It Will Get
Better." Android Police Android News Apps Games Phones Tablets. Android Police, 12 Nov. 2013. Web.
22 Apr. 2014.
Toombs, Cody. "Meet ART, Part 3: Battery Life Benchmarks - Not Good, But Not Too Bad." Android Police
Android News Apps Games Phones Tablets. Android Police, 22 Jan. 2014. Web. 25 Apr. 2014.