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.

Key Android Concepts

No doubt, you are in a hurry to get started with Android application development. After all, you are reading this book, aimed at busy coders.

However, before we dive into getting tools set up and starting in on actual programming, it is important that we “get on the same page” with respect to several high-level Android concepts. This will simplify further discussions later in the book.

Android Applications

This book is focused on writing Android applications. An application is something that a user might install from the Play Store or otherwise download to their device. That application should have some user interface, and it might have other code designed to work in the background (multi-tasking).

This book is not focused on modifications to the Android firmware, such as writing device drivers. For that, you will need to seek other resources.

This book assumes that you have some hands-on experience with Android devices, and therefore you are familiar with buttons like HOME and BACK, the built-in Settings application, the concept of a home screen and launcher, and so forth. If you have never used an Android device, you are strongly encouraged to get one (new or used) and spend some time with it before starting in on learning Android application development.

Programming Language

The vast majority of Android applications are written exclusively in Java. Hence, that is what this book will spend most of its time on and will demonstrate with a seemingly infinite number of examples.

However, there are other options:

Some of this will be covered later in the book, but the vast majority of this book is focused on Java-based app development.

The author assumes that you know Java at this point. If you do not, you will need to learn Java before you go much further. You do not need to know everything about Java, as Java is vast. Rather, focus on:

The links are to Wikibooks material on those topics, though there are countless other Java resources for you to consider.

Google also supports Kotlin as a programming language for Android apps. Kotlin can be used as a replacement for Java. While Kotlin has plenty of benefits, it is also a relatively new programming language. This book is focused on the Android SDK, more so than on Java (or Kotlin), and so regardless of which of those two languages you use, the material in this book will be relevant. This book’s examples are mostly in Java, due to that being the dominant Android app development language today.


When you first learned Java — whether that was yesterday or back when dinosaurs roamed the Earth — you probably started off with something like this:

class SillyApp {
    public static void main(String[] args) {
        System.out.println("Hello, world!");

In other words, the entry point into your application was a public static void method named main() that took a String array of arguments. From there, you were responsible for doing whatever was necessary.

However, there are other patterns used elsewhere in Java. For example, you do not usually write a main() method when writing a Java servlet. Instead, you extend a particular class supplied by a framework (e.g., HttpServlet) to create a component, then write some metadata that enumerates your components and tell the framework when and how to use them (e.g., WEB.XML).

Android apps are closer in spirit to the servlet approach. You will not write a public static void main() method. Instead, you will create subclasses of some Android-supplied base classes that define various application components. In addition, you will create some metadata that tells Android about those subclasses.

There are four types of components, all of which will be covered extensively in this book:


The building block of the user interface is the activity. You can think of an activity as being the Android analogue for the window or dialog in a desktop application, or the page in a classic Web app. It represents a chunk of your user interface and, in some cases, a discrete entry point into your app (i.e., a way for other apps to link to your app).

Normally, an activity will take up most of the screen, leaving space for some “chrome” bits like the clock, signal strength indicators, and so forth.

However, bear in mind that on some devices, the user will be able to work with more than one activity at a time, such as split-screen mode on a phone or tablet. So, while it is easy to think of activities as being equivalent to the screen, just remember that this is a simplification, and that reality is more complicated (as reality often is).


Activities are short-lived and can be shut down at any time, such as when the user presses the BACK button. Services, on the other hand, are designed to keep running, if needed, independent of any activity, for a moderate period of time. You might use a service for checking for updates to an RSS feed, or to play back music even if the controlling activity is no longer operating. You will also use services for scheduled tasks (akin to Linux or macOS “cron jobs”) and for exposing custom APIs to other applications on the device, though the latter is a relatively advanced capability.

Content Providers

Content providers provide a level of abstraction for any data stored on the device that is accessible by multiple applications. The Android development model encourages you to make your own data available to other applications, as well as your own — building a content provider lets you do that, while maintaining a degree of control over how your data gets accessed.

So, for example, if you have a PDF file that you downloaded on behalf of the user, and you want to allow the user to view that PDF file, you might create a content provider to make that PDF file available to other apps. You can then start up an activity that will be able to view that PDF, where Android and the user will determine what PDF-viewing activity handles that request.

Broadcast Receivers

The system, or applications, will send out broadcasts from time to time, for everything from the battery getting low, to when the screen turns off, to when connectivity changes from WiFi to mobile data. A broadcast receiver can arrange to listen for these broadcasts and respond accordingly.

Widgets, Containers, and Resources

Most of the focus on Android application development is on the UI layer and activities. Most Android activities use what is known as “the widget framework” for rendering their user interface, though you are welcome to use the 2D (Canvas) and 3D (OpenGL) APIs as well for more specialized GUIs.

In Android terms, a widget is the “micro” unit of user interface. Fields, buttons, labels, lists, and so on are all widgets. Your activity’s UI, therefore, is made up of one or more of these widgets. This is a common approach in most UI toolkits, and so most likely you have already worked with buttons, labels, fields, and similar sorts of widgets somewhere else previously.

If you have more than one widget — which is fairly typical — you will need to tell Android how those widgets are organized on the screen. To do that, you will use various container classes referred to as layout managers. These will let you put things in rows, columns, or more complex arrangements as needed.

To describe how the containers and widgets are connected, you will typically create a layout resource file. Resources in Android refer to things like images, strings, and other material that your application uses but is not in the form of some programming language source code. UI layouts are another type of resource. You will create these layouts either using a structured tool, such as an IDE’s drag-and-drop GUI builder, or by hand in XML form.

Sometimes, your UI will work across all sorts of devices: phones, tablets, televisions, etc. Sometimes, your UI will need to be tailored for different environments. You will be able to put resources into resource sets that indicate under what circumstances those resources can be used (e.g., use these for normal-sized screens, but use those for larger screens).

We will be examining all of these concepts, in much greater detail, as we get deeper into the book.

Apps and Packages

Given a bucket of source code and a basket of resources, the Android build tools will give you an application as a result. The application comes in the form of an APK file. It is that APK file that you will upload to the Play Store or distribute by other means.

Each Android application has a package name, also referred to as an application ID. A package name must fulfill three requirements:

  1. It must be a valid Java package name, as some Java source code will be generated by the Android build tools in this package
  2. No two applications can exist on a device at the same time with the same application ID
  3. No two applications can be uploaded to the Play Store having the same application ID

When you create your Android project — the repository of that source code and those resources — you will declare what package name is to be used for your app. Typically, you will pick a package name following the Java package name “reverse domain name” convention (e.g., That way, the domain name system ensures that your package name prefix (com.commonsware) is unique, and it is up to you to ensure that the rest of the package name distinguishes one of your apps from any other.

Android Devices

There are well in excess of one billion Android devices in use today, representing thousands of different models from dozens of different manufacturers. Android itself has evolved since Android 1.0 in 2008. Between different device types and different Android versions, many a media pundit has lobbed the term “fragmentation” at Android, suggesting that creating apps that run on all these different environments is impossible.

In reality, it is not that bad. Some apps will have substantial trouble, but most apps will work just fine if you follow the guidance presented in this book and in other resources.


Android devices come in all shapes, sizes, and colors. However, there are three dominant “form factors”:

Beyond that, there are several less-common form factors

You will often hear developers and pundits refer to these form factors, and this book will do so from time to time as well. However, it is important that you understand that Android has no built-in concept of a device being a “phone” or a “tablet” or a “TV”. Rather, Android distinguishes devices based on capabilities and features. So, you will not see an isPhone() method anywhere, though you can ask Android:

Similarly, as you build your applications, rather than thinking of those form factors, focus on what capabilities and features you need. Not only will this help you line up better with how Android wants you to build your apps, but it will make it easier for you to adapt to other form factors that will come about such as:

The Emulator

While there are ~2 billion Android devices representing ~10,000 device models, probably you do not have one of each model. You may only have a single piece of Android hardware. And if you do not even have that, you most certainly will want to acquire one before trying to publish an Android app.

To help fill in the gaps between the devices you have and the devices that are possible, the Android developer tools ship an emulator. The emulator behaves like a piece of Android hardware, but it is a program you run on your development machine. You can use this emulator to emulate many different devices, with different screen sizes and Android OS versions, by creating one or more Android virtual devices, or AVDs.

In an upcoming chapter, we will discuss how you install the Android developer tools and how you will be able to create these AVDs and run the emulator.

OS Versions and API Levels

Android has come a long way since the early beta releases from late 2007. Each new Android OS version adds more capabilities to the platform and more things that developers can do to exploit those capabilities.

Moreover, the core Android development team tries very hard to ensure forwards and backwards compatibility. An app you write today should work unchanged on future versions of Android (forwards compatibility), albeit perhaps missing some features or working in some sort of “compatibility mode”. And there are well-trod paths for how to create apps that will work both on the latest and on previous versions of Android (backwards compatibility).

To help us keep track of all the different OS versions that matter to us as developers, Android has API levels. A new API level is defined when an Android version ships that contains changes that affect developers. When you create an emulator AVD to test your app, you will indicate what API level that emulator should emulate. When you distribute your app, you will indicate the oldest API level your app supports, so the app is not installed on older devices.

At the time of this writing, the API levels of significance to most Android developers are:

Here, “of significance” refers to API levels that have a reasonable number of Android devices — 5% or more, as reported by the “Platform Versions” dashboard chart.

The latest version of Android is 8.1, API Level 27. There is also a developer preview of Android P available — presumably, this will turn into API Level 28 later in 2018.

Note that API Level 20 was used for the version of Android 4.4 running on the first-generation “Android Wear” devices (now referred to as “Wear OS”). Unless you are specifically developing apps for Wear, you will not be worrying much about API Level 20.

Dalvik and ART

In terms of Android, Dalvik and ART are virtual machines (VM)s. Virtual machines are used by many programming languages, such as Java, Perl, and Smalltalk. Dalvik and ART are designed to work much like a Java VM, but optimized for embedded Linux environments.

Primarily, the difference between the two is that ART is used on Android 5.0 and higher, while Dalvik was used on older devices. In truth, the story is more complicated than this, but this will do for now.

So, what really goes on when somebody writes an Android application is:

  1. Developers write Java-syntax source code, leveraging class libraries published by the Android project and third parties.
  2. Developers compile the source code into Java VM bytecode, using the javac compiler that comes with the Java SDK.
  3. Developers translate the Java VM bytecode into Dalvik VM bytecode, which is packaged with other files into a ZIP archive with the .apk extension (the APK file).
  4. An Android device or emulator runs the APK file, causing the bytecode to be executed by an instance of a Dalvik or ART VM.

From your standpoint, most of this is hidden by the build tools. You pour Java source code into the top, and the APK file comes out the bottom.

However, there will be places from time to time where the differences between the Dalvik VM and the traditional Java VM will affect application developers, and this book will point out some of them where relevant.

Processes and Threads

When your application runs, it will do so in its own process. This is not significantly different than any other traditional operating system. Part of Dalvik’s magic is making it possible for many processes to be running many Android applications at one time without consuming ridiculous amounts of RAM.

Android will also set up a batch of threads for running your app. The thread that your code will be executed upon, most of the time, is variously called the “main application thread” or the “UI thread”. You do not have to set it up, but, as we will see later in the book, you will need to pay attention to what you do and do not do on that thread. You are welcome to fork your own threads to do work, and that is fairly common, though in some places Android handles that for you behind the scenes.

Don’t Be Scared

The preview of this section was accidentally identified as an Android 'tasty treat' by the Cookie Monster.