Native tools include many standard Linux command-line tools, as well as the init process that is responsible for starting all the native daemons, among other things.
Like most other operating systems, Android has a command-line shell where developers can poke around the system. On Android, developers access this shell via ADB, which we’ll go over later. However, if you are an experienced Linux user, you’ll quickly notice that the set of commands available in the standard Android release is far smaller than other typical Linux distributions. That’s because Android uses toolbox to support most of these command-line tools, such as cd, ls, ps, top, df, and so on. If you are used to Linux, do not expect to find grep, vi, less, more, or any other of the common developer tools. That’s why platform developers often tend to replace the standard Android tool box with the Linux busybox. However, doing that is well beyond the scope of this book, because it gets into details of the Android internals.
Dalvik
Dalvik is a purpose-built virtual machine designed specifically for Android.
The Java virtual machine (VM) was designed to be a one-size-fits-all solution, and the Dalvik team felt it could do a better job by focusing strictly on mobile devices. It looked at which constraints specific to a mobile environment are least likely to change in the future. One of these is the limited battery life, and the other is the size of ever-shrinking mobile devices. Dalvik was built from the ground up to address those constraints.
To address the battery constraint, Dalvik was designed as a registry-based virtual ma‐
chine, which makes it suitable for ARM-based chips. ARM tends to run much cooler than the equivalent Intel x86 type of architecture, and thus consumes less battery, which x86 chips tend to waste on heat. The standard Java VM, by comparison, is stack-based,
making it suitable for today’s powerful PCs and servers, most of which are plugged into the wall.
To address the size issue, Dalvik does some interesting things. When instantiating an object, the standard Java VM would locate the class file for that object on the disk and then load it into RAM. That makes sense because the disk on a typical PC or server is mechanical, thus it reads and writes at relatively slow speeds compared to RAM. Mobile devices, on the other hand, do not use hard drives but rely on solid state memory for both RAM as well as “disk” storage. To minimize doubling of limited available memory, Dalvik “loads” the class file directly on the disk, by pointing to its location. It copies into RAM only things that change, using a copy-on-write algorithm. This allows for much lower total memory usage.
Also, each Android application runs in its own process in order to provide for applica‐
tion sandboxing, which is the cornerstone of the Android security model. That means that at any point in time, your Android device may have a dozen or more Dalvik VMs loaded in memory. To minimize total memory consumption, Dalvik itself is made to have a tiny memory footprint, as well as to share system libraries instead of creating a copy for each instance.
Another side effect of replacing the Java VM with the Dalvik VM is the licensing.
Whereas the Java language, Java tools, and Java libraries are free, the Java virtual machine is not. This was more of an issue back in 2005 when the work on Dalvik started. Nowa‐
days, there are open source alternatives to Sun’s Java VM, namely the OpenJDK and Apache Harmony projects. Though Android uses Apache Harmony for its Java libraries, it relies on Dalvik for the execution of the code.
By developing a truly open source and license-friendly virtual machine, Android yet again provides a full-featured platform that others are encouraged to adopt for a variety of devices without having to worry about the license.
Dalvik was developed by Dan Bornstein and his team at Google. He named it after Dalvik, a fisherman village in Iceland. As a tribute to this virtual machine, the author got a California license plate that says DALVIK. Honk if you see it on the road!
Android and Java
In Java, you write your Java source file, compile it into Java byte code using the Java compiler, and then run this byte code on the Java VM. In Android, things are different.
You still write the Java source file, and you still compile it to Java byte code using the same Java compiler. But at that point, you recompile it once again to Dalvik byte code using the Dalvik compiler. It is this Dalvik byte code that is then executed on the Dalvik
Dalvik | 37
VM. Figure 3-2 illustrates this comparison between standard Java (on the left) in An‐
droid using Dalvik (on the right).
Figure 3-2. Java versus Dalvik
It might sound like you have to do a lot more work with Android when it comes to Java. However, all these compilation steps are au‐
tomated by tools such as Eclipse or Ant, and you never notice the additional steps.
You may wonder, why not compile straight from Java into the Dalvik byte code? There are a couple of good reasons for the extra steps. Back in 2005, when work on Dalvik started, the Java language was going through frequent changes, but the Java byte code was more or less set in stone. So, the Android team chose to base Dalvik on Java byte code instead of Java source code.
A side effect of this is that you can write Android applications in another language that compiles down to Java byte code. For example, you could use Scala, or Python, or Ruby to code your Android app. We’re seeing some early development of apps and frameworks to support other languages and make Android development appealing to an even wider developer audience.
Another thing to keep in mind is that Android Java is a nonstandard collection of Java classes. Java typically ships in:
Java Standard Edition
Used for development on basic desktop-type applications Java Enterprise Edition (a.k.a. J2EE or JavaEE)
Used for development of enterprise applications Java Micro Edition (a.k.a. J2ME or JavaME)
Java for mobile applications
Android’s Java set of libraries is closest to Java Standard Edition. The major difference is that Java user interface libraries (AWT and Swing) have been taken out and replaced with Android-specific user interface libraries. Android also adds quite a few new fea‐
tures to standard Java while supporting most of Java’s standard features. So, you have most of your favorite Java libraries at your disposal, plus many new ones.