The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.

JARs and Library Projects

Java has as many, if not more, third-party libraries than any other modern programming language. Here, “third-party libraries” refer to the innumerable JARs that you can include in a server or desktop Java application — the things that the Java SDKs themselves do not provide.

In the case of Android, the virtual machine (VM) at its heart is not precisely Java, and what it provides in its SDK is not precisely the same as any traditional Java SDK. That being said, many Java third-party libraries still provide capabilities that Android lacks natively and therefore may be of use to you in your project, for the ones you can get working with Android’s flavor of Java. This chapter explains what it will take for you to leverage such libraries and the limitations on Android’s support for arbitrary third-party code.

You might think that JARs are the primary model of code reuse within Android. That’s not really the case. The primary model of code reuse within Android is the Android library project. Many reusable components and frameworks are distributed as library projects, and we will see several in the course of this book.

The example described in this chapter is the Android Support package, a key piece of reusable code from Google itself, distributed partly as JARs and partly as an Android library project.

But first, let’s talk a bit more about Android and VMs.

The Dalvik VM, and a Bit of ART

When you are writing Android applications, you are writing Java source code. You might be thinking that your Android device is running Java bytecode, just as your Web browser might when it runs a Java applet.

Alas, you would be mistaken.

Android does not have a Java VM. Android has the Dalvik VM or ART.

The Dalvik VM is a virtual machine, along the lines of the Java VM, the Parrot VM (Perl), Microsoft’s CLR, and so forth. Since each VM has its own bytecode, the Dalvik VM bytecode is not the same as the Java VM bytecode (or the Parrot VM bytecode, etc.).

When you build your project, your Java source code is initially compiled using the standard javac compiler. Then, however, the Java VM bytecodes created by javac are cross-compiled into Dalvik VM bytecodes, and it is those bytecodes that are packaged into your APK file and are executed by Android.

Most of the time, you will not notice the difference. Every now and then, though, you will encounter some issues related to Android’s use of Dalvik, and the most prominent of these comes when you try repurposing existing Java code.

ART is a new runtime, available for developer testing in Android 4.4. ART still uses Dalvik bytecodes, but uses them as input for an ahead-of-time (AOT) compiler. Rather than relying on a just-in-time (JIT) compiler, as the Dalvik VM does, to translate Dalvik bytecodes into CPU-specific instructions, ART’s AOT compiler converts all the bytecodes to instructions at installation time.

Getting the Library

You have two easy choices for integrating third-party Java code into your project: use JARs or use an artifact in a repository. The latter approach is for Android Studio users; any IDE can use JARs.

Ideally, the documentation for the third-party library will tell you how to get it as an artifact and add it to your Android Studio project. Specifically, it should tell you a line that you should add to your dependencies closure of your app’s build.gradle file, such as compile 'com.squareup.retrofit:retrofit:1.6.1'. We will get into the details of what this line means much later in the book.

The documentation should also indicate what artifact repository this artifact comes from. It may tell you that the artifact comes from “Maven” or “Maven Central”, in which case you will need a mavenCentral() line in your repositories closure:

repositories {

Or, it may tell you something else to use, if the artifact is from another repository, such as:

repositories {
    maven {
        url ""

So, for example, you might wind up with the following in your app’s build.gradle file:

repositories {

dependencies {
    compile 'com.squareup.retrofit:retrofit:1.6.1'

If you have an artifact name (e.g., com.squareup.retrofit:retrofit:1.6.1), and you have no indication of where the artifact comes from, try the mavenCentral() option.

If all you have is a JAR file, put it in a libs/ directory in your project’s app/ folder, and then make sure that your dependencies closure has the compile fileTree... line in it to pull JARs from libs/:

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])

Much more about Android Studio, Gradle, and dependencies can be found later in the book, but this should help you get started.

The Outer Limits

The preview of this section will not appear here for a while, due to a time machine mishap.

JAR Dependency Management

The preview of this section was last seen in the Bermuda Triangle.

OK, So What is a Library Project?

The preview of this section was eaten by a grue.

Using a Library Project

The preview of this section was last seen in the Bermuda Triangle.

Library Projects: What You Get

The preview of this section was abducted by space aliens.

The Android Support Package

The preview of this section is in an invisible, microscopic font.