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

The preview of this section did not survive Thanos's finger snap.

Don’t Be Scared

The preview of this section is presently indisposed.