Fine-Tuning Your Development Environment - Building a Better Foundation - Android Programming: Pushing the Limits (2014)

Android Programming: Pushing the Limits (2014)

Part I. Building a Better Foundation

Chapter 1. Fine-Tuning Your Development Environment

Depending on what you’re developing, you have different choices when it comes to the tools you can use.

Your requirements on the development environment differs if you’re writing an HTML5 application or if you’re

developing a server-side application in Java. Some platforms offer more choice than others, and as I describe

next, developing Android applications gives you a lot of choice for your development environment.

I begin this chapter with some more advanced internals of the Android SDK and how you can use them in

your daily development and how they can assist you in improving the quality of your application. I continue

by describing how to structure your code projects in an optimal way for reuse by using library projects. You

also learn how to take version control to a new level by integrating Git with a code-review tool called Gerrit.

As a developer, you will spend most of your time using the IDE tool. While the Eclipse IDE is still supported by

Google, they are now pushing developers to use their new Android Studio IDE for all Android projects. So, I give

an introduction to Android Studio as well as to the new build system called Gradle. Finally, I go through the

developer settings that are available on Android devices.

Operating Systems for Android Development

This is probably the one topic you don’t have to worry about. Either you can pick the operating system on

your computer used for development, or it is limited by the IT-policies of your employer. For most Android

developers, any of the officially supported operating systems works fine. However, there are situations where

the choice will matter.

Google supports Windows, Linux, and OS X for developing Android applications. Although Windows is officially

supported by the Android SDK, you’ll have problems if you decide to do advanced development, especially

when it comes to writing native applications or building your own custom ROM. The best choice is either Linux

or OS X. If possible, try to have one of these as your primary operating system, and you’ll run into far fewer

problems. Another reason for avoiding Windows on your Android development environment is that you won’t

need to install new USB drivers for every Android device you work on.

Advanced Android SDK Tools

After you have your operating system and the required (and recommended) tools installed on your computer,

you can focus on the Android SDK. You will find the download for your operating system and the latest

installation instructions at Android Studio comes with an SDK

bundle that is completely managed from within the IDE, but if you prefer to have a standalone version you can

download that as well.

Make sure that you always keep the SDK up to date and that you download the APIs for all the Android versions

that you’re developing for. The easiest way to update your standalone Android SDK is to run the update tool

from the command prompt:

$ android update sdk --no-ui

Inside the Android SDK folder, you will find a number of subfolders. From a tools perspective, only the

platform-tools and tools folders are of interest for now. I will introduce some of these tools and explain

how to use them, starting with the adb (Android Debug Bridge) tool. If you are frequently using the command

line tools in the Android SDK I recommend that you add the path to these folders in your local PATH variable.

You can find the official documentation for most of the tools in the Android SDK at http://

The adb Tool

In the platform-tools folder, you will find the adb tool that is used to communicate with your device to

install and start apps during development. In earlier versions of the Android SDK, this tool was found in the

tools directory, but it has since been moved. Besides being used for installing, starting, and debugging

applications from your IDE, the adb tool enables you to manually call many of the low-level operations on your

Android device for debugging purposes. To list all the commands available, simply type adb help all in

your terminal (Linux or Mac OS X) or command prompt (Windows).

Some common adb commands are

■ adb devices—List all connected Android devices and Emulators.

■ adb push <local> <remote>—Copy a file from your computer to a device (usually on the SD card).

■ adb pull <remote> <local>—Copy a file from the device to your computer.

adb and Multiple Devices

If you ever need to develop and debug an application for two or more devices simultaneously, such as for a

multiplayer game or an instant-message application, adb needs an additional argument to know which device

you want to address. You do so by adding –s <serial number> as the first parameter to adb. You can see

the serial number for your connected devices by executing the adb devices command. To run the logcat

command on a specific device, run the following:

$ adb devices

List of devices attached

0070015947d30e4b device

015d2856b8300a10 device

$ adb –s 015d2856b8300a10 logcat

When you have multiple devices connected or emulators started a dialog box will appear when you

launch your application in your IDE.

Mastering Logcat Filtering

Logging is an important part of Android application development. Although using breakpoints and a debugger

from your IDE is extremely powerful when you want to follow the execution flow and inspect the values and

state of different variables, simply reading the output from logcat can sometimes be more efficient. Android

logging is handled by the logcat function, which is usually integrated in your IDE but can also be called via

the adb command.

Because Android outputs all system and application log messages to the same stream, it can become quite

complicated to find the messages that relate to your application. Luckily, there are some easy ways to filter the

logs, as I show in the following code.

Android log messages are prepended with a tag and a priority. Usually, you declare a separate log tag for each

class in your application like this:

private static final String TAG = “MyActivity”;

You can then use this tag when printing a log message somewhere in the code for that class:

Log.d(TAG, “Current value of moderation: “ + moderation);

To filter out all log messages except those that have MyActivity as the value for the tag, you can execute

logcat as follows.

$ adb logcat MyActivity:* *:S

The parameters after logcat are the filters you want to apply. They are formatted as <tag>:<priority>

where an asterisk (*) indicates all possible values. One important thing that can easily be missed is that you

must include the special filter *:S, which tells logcat to silence all messages. In combination with your own

filters, you can easily control logcat to print only the messages you want to see.

If you use filters when viewing the logcat output, I also recommend adding AndroidRuntime:*. This will

show you relevant information from the Android system as well as exceptions that are generated by your

application but caught by the platform.

Connecting adb over Wi-Fi

Usually, you connect to your Android device using a USB cable plugged into your computer. However, you can

also connect to an Android device over Wi-Fi using a standard TCP/IP connection. This can be very useful when

developing applications that are listening for events related to USB (since then the normal connection to your

computer will interfere), like connected/disconnected or when you simply don’t want to bother with USB cables

during development.

In order to enable adb connection over Wi-Fi, you first need to plug your device into your computer using USB as

you normally do. Also, make sure your computer and your Android device are connected to the same Wi-Fi. You also

need to know the IP address of your Android device, which you can find on your device by choosing Settings➪

Wi-Fi➪Advanced. In the bottom of the list that appears you will find your device IP address for the current Wi-Fi.

After you have this set up correctly, run the following commands from your terminal:

$ adb devices

List of devices attached

0070015947d30e4b device

$ adb tcpip 5555

$ adb connect

$ adb devices

List of devices attached device

The first command is just to verify that your device is connected in debugging mode. The second command tells

the device to restart the adb daemon on the device in TCP/IP mode and listen on port 5555 (the default port for

adb). The third command tells the adb Service on your computer to connect to the IP address (using default

port 5555) of the device. Finally, the fourth command verifies that the computer is connected to the device over

TCP/IP. You can now unplug the USB cable from your device and start developing with your IDE as usual.

The device will keep the adb daemon in TCP/IP mode until it is restarted or until you run the command adb

usb, which restarts the adb daemon in USB mode.

Connecting adb over WiFi is not guaranteed to work on all devices. Also, the communication

performance with the device is much worse, which can be annoying when you need to deploy a large


Executing Commands on an Android Device

Because an Android system is basically a custom Linux distribution, you can interact with it in much the same

way as you can with Linux on your PC. By running a special adb command, you can start a standard Linux-shell

on your Android device that lets you perform command-line operations in the same way as you do on your

other Linux installations as shown here.

$ adb shell

When running a shell on your Android device, two useful commands are am and pm. These commands aren’t

related to the time of day; instead, they enable you to interact with the Application and Package Managers,

respectively, which can be useful during early development and testing. For instance, if you’re implementing a

Service that will be started by some externally triggered Intent, you can manually send this Intent using

the am command.

To start a Service using an Intent action, simply type the following on the command line:

$ adb shell am startservice –a <intent action>

You can add parameters for extras and even specify a certain component name. In addition to startservice,

you can launch an Activity or send a broadcast Intent. Calling adb shell am without additional

parameters will display a full list of possible commands. You will find that this command is especially

useful when you start developing an Android application and need to test a Service before you create

the Activity that will launch it. Also, it’s useful for simulating Intents that will be launched by other

applications, such as ACTION_VIEW or ACTION_SEND.

The Package Manager is a central Android component that manages the installed applications on a device.

You can control use of the pm command in a similar way to how you work with the Application Manager.

The Package Manager lets you interact with the installed applications (packages), allowing you to list, install,

uninstall, and inspect the features and permissions on the device. Although the pm command isn’t as useful

during development as the am command, it can sometimes be helpful if you want to find out details about the

device that are otherwise a bit complicated to discover. For instance, if you want to list all the installed packages

(that is, installed apps), you can type the following:

$ adb shell pm list packages

In addition to the adb commands just covered, there are many others you need to be familiar with. If you

haven’t done so already, take some time to experiment with the adb commands.

You can find a list of adb commands and their uses at


Stress-Testing an Application’s UI with Monkey

Most developers often consider testing a tedious and boring task, and Android developers are probably no

exception. A good developer handles testing by writing automated tests that verify parts of the code in the

application when running on the device. You can also find code inspection tools that search for common

coding mistakes (you’ll look at one of these in the section “Static Code Analysis with Lint,” later in this chapter).

However, as much as you might wish, writing automated tests and performing static code analysis is never

100% foolproof. A user doesn’t behave according to a certain pattern all the time. Users can click a button at

an unexpected moment or accidentally click the wrong button, which can cause your application to crash. You

basically need something that behaves like a user would, or better yet, like a monkey would!

The Android SDK comes with a powerful tool called the Application Exerciser Monkey, or simply, Monkey . This

is a command-line tool that allows you to generate pseudo-random user events like touches or system events

on a device. The purpose is to stress test your application by simulating what a user could do. Although Monkey

doesn’t simulate a typical use-case scenario for your application, it provides valuable feedback on how your

application will work if the user interacts with your user interface in an unpredictable way.

The following command executes the Monkey tool on an application with the specific <package name> and

injects as many random events as specified by <event count>.

$ adb shell monkey –p < package name> < event count>

The default behavior for Monkey is to stop when an unhandled exception occurs and to report the error. This

behavior is useful for finding things like unexpected NullPointerExceptions or similar issues in your

code. You can fine-tune the behavior through various parameters and tell Monkey to halt only if, for instance, a

security exception occurs.

Scripting Monkey with Monkeyrunner

A more advanced way of executing Monkey on your application is by writing a Python script that uses the

Monkeyrunner API. This can be very useful in a continuous development environment where you want to run

the Monkey tool and perform other actions as well. It also allows you to provide input values for keystrokes and

capture screen shots programmatically that can be compared (also using the Monkeyrunner API) to a set of

screen shots known to be correct.

For a team of Android developers, this can prove to be a huge advantage because it provides a robust

regression-testing solution with very little effort. Even small changes to your code can sometimes provide

unexpected results that can be very difficult to detect when you’re the only person testing the application

before release. Using the Monkey tool, and preferably building Monkeyrunner scripts for regression testing, is

highly recommended before publishing your application.

You can find the API for the Monkeyrunner at


The Gradle Build System for Android

With the release of Android Studio, Google also introduced a new modular build system that replaces the old

Ant scripts that were generated by the older versions of the SDK. When you create a new project in Android

Studio, it will also create all the Gradle scripts for your project.

Gradle is a modular build system similar to Ivy and Maven. It combines the flexibility of Ant with the

dependency management from Maven. Instead of writing build-scripts in complex XML-files, Gradle has its own

Groovy DSL (Domain-Specific Language) that allows you to express more clearly your build configuration.

The following code is the default build.gradle file that is generated for new projects. The first block tells

gradle which repository to download plug-ins and dependencies for the build. (This is not the same as the

dependencies for your project, which is defined in a later block.) The next part tells Gradle to apply a plug-

in, in this case the Android plug-in, which enables the specifics for Android development. Next come the

dependencies for your project, in this case only the support library that is located in the libs directory of your

project. The final block, starting with android, specifies the configuration for your project.

buildscript {

repositories {

maven { url ‘’ }


dependencies {

classpath ‘’



apply plugin: ‘android’

dependencies {

compile files(‘libs/android-support-v4.jar’)


android {

compileSdkVersion 18

buildToolsVersion “18.0.0”

defaultConfig {

minSdkVersion 18

targetSdkVersion 18



The user guide for the new Gradle build system can be found at


The default directory structure for an Android project using the new build system is slightly different from what

you may be used to. Instead of having a flat structure, there are two main source sets: source code and test

sources. They are in the following directories:



Under the main directory the Java source code is placed in the java and resources are placed in the res

directory. The AndroidManifest.xml file is located directly in the main directory (see Figure 1-1).

The other directories for project files are assets (for binary assets), aidl (for Android IDLs), rs (RenderScript

sources) and jni (native C/C++ code).

While building and running your project is supported directly in the Android Studio IDE, you can interact with

the build system through the command line as well. Gradle defines a number of tasks and to list all available

tasks, simply type the following from the root of your Android project.

$ ./gradlew tasks

If you, for instance, want to build the application from scratch you would run the following.

$ ./gradlew clean build

This will execute first the clean task, followed by the build task.


Figure 1-1: The directory structure and Gradle build file shown in the Android Studio IDE

Migrating Existing Projects to Gradle

Since most existing Android projects are not using the Gradle build system, a migration guide might be in

order. The easiest way to migrate is to create a new Android project using Android Studio. Then, copy your own

project to a sub-folder in the new project.

Next, take the build.gradle file for the application created by Android studio and copy it to the root of your

own application.

android {

sourceSets {

main {

manifest.srcFile ‘AndroidManifest.xml’

java.srcDirs = [‘src’]

resources.srcDirs = [‘src’]

aidl.srcDirs = [‘src’]

renderscript.srcDirs = [‘src’]

res.srcDirs = [‘res’]

assets.srcDirs = [‘assets’]




Edit the android section of the file so that it looks like the previous example. This should work well for

all existing Android projects that follow the old standard directory structure. If your project has a different

structure, simply change the paths from the previous example. (Note that all paths are relative.)

Optimize and Obfuscate with ProGuard

An Android application is the compiled result from your Java, XML, and other resource files. The Java code is

compiled into a binary format called dex, which is what the Dalvik virtual machine on Android reads when

executing your code. This format is not designed to be human-readable, tools are available for decompiling a

dex file back to a human-readable format.

In some cases, decompiling the code can be a security issue—for instance, when your code contains keys or

other values that should not be easily accessible (such as integration with Licensing Server). Although it isn’t

possible to completely prevent decompilation of your code, you can make it much more difficult by obfuscating

it before you publish it. This method will make reverse engineering much more time-consuming and hopefully

discourage hacking attempts on your application.

You obfuscate your code for Android by using the ProGuard tool that’s integrated in the Android SDK. The tool

is supported by the Gradle build system, and all you need to do is to add the following to the android section in


buildTypes {

release {

runProguard true

proguardFile getDefaultProguardFile(‘proguard-android.txt’)



This will enable ProGuard to be applied to the release-build of your application. During normal development

this step is excluded.

Another reason to obfuscate your code is that doing so performs some additional optimizations, as well as

shrinking the resulting dex binary by removing unused code. This is especially useful when you’ve included a

large third-party library, because it can significantly reduce the final file size and memory usage during runtime.

Android Library Projects and Third-Party Libraries

Developers tend to write the same code over and over for new applications, which is why we create code

libraries that can be reused in the next project. The result is a faster development cycle because there’s less code

to write and test.

Android offers you two ways to reuse code among your application projects: by using either a precompiled

JAR file or a library project. The first method is preferable when you’re dealing with third-party code that you

don’t control or when you have a stable and complete set of library functions that won’t change during the

current project. The second method, using a library project, is useful if you’re developing multiple applications

in the same project that will share some code—for example, when you’ve decided to create one application

for smartphones and one for tablets, or when you have two different applications that will communicate (for

example, client and server).

Precompiled JAR Libraries

Using a precompiled JAR file in your Android project is very simple. Simply copy the file to the libs directory in

your project folder and then add it as a library within your IDE. The code in the JAR file will be available directly,

and when you build the application, the Android tool chain will automatically include and package the included

classes. If you’re obfuscating your application code with ProGuard, all included JAR files will be processed as

well. This is especially useful when you’re including large third-party libraries where you use only part of the

classes it provides. To include a local JAR file as a dependency to your project, simply add it to the dependency

section in build.gradle like this:

dependencies {

compile files(‘libs/android-support-v4.jar’)


Another way of doing this is by using a remote dependency repository, such as the central Maven repository.

To enable this and include a third-party library found in that repository, you update your build.gradle as


repositories {



dependencies {

compile ‘’


The string in the dependencies section is an identifier for a specific version of a library. The call to

mavenCentral() will configure your build environment with the correct Maven settings.

To search for third-party libraries you can use the Maven search site at http://search.maven.

org/. Once you’ve found the right library, simply click on the version and copy the identifier

string from the Grails section. Note that not all libraries found on the central Maven repository are

supported on Android. Refer to the documentation first.

Setting Up a Library Project

An Android library project is basically a standard Android project that doesn’t declare any components that can

be started (Activities, Services, BroadcastReceivers, or ContentProviders) and that won’t

generate an APK when compiled or exported. The library’s sole purpose is to be shared by multiple application

projects so that you don’t have to copy the same code between them, which is very useful for sharing constants,

utility functions, common custom views, and other components. Because you’re dealing with the actual code and

not a precompiled JAR file, the code can be changed, which will affect all the applications that include this library.

Because Android development uses the Java programming language, using a library project to share code

between an Android application and a server-side component written in Java (for instance, a Java Enterprise

application) can be especially useful. Common code to share in such a setup is the class representation of the

shared data and how to serialize and deserialize objects of these classes.

The Android SDK comes with a number of ready-to-use library projects that can be found under extras/

google in the SDK folder. More specifically, you can find library projects for the Play Services, APK extensions,

In-app Billing and Licensing features. To use these, you simply have to import them into your IDE and add a

dependency to your own project. Note: You can refer to multiple library projects in one application project.

You can set up a library project from the Android Studio IDE. Simply create a new module and choose Android

Library as the module type. A will be generated for the new library project as shown next.

buildscript {

repositories {

maven { url ‘’ }


dependencies {

classpath ‘’



apply plugin: ‘android-library’

dependencies {

compile files(‘libs/android-support-v4.jar’)


android {

compileSdkVersion 17

buildToolsVersion “17.0.0”

defaultConfig {

minSdkVersion 7

targetSdkVersion 16



Note that the only difference from the default build file for Android project is the use of the plug-in android-

library instead of android.

To include a library project in your application’s build configuration, you simply refer to it as a dependency as

shown in the following.

dependencies {

compile project(‘:libraries:MyLibrary’)


Version Control and Source Code Management

Chances are that most development projects you’ll work on will involve other developers. A development

team usually comprises four to eight people, all working on the same code in parallel. Although the team could

decide who will make the changes for every file, it’s much more practical to apply a version control system to the

project files that supports a parallel method for development. Another benefit of a version control system is

that you can track changes back in time (who made what changes and when in a specific part of a file) and then

merge changes from different developers into the same file.

One of the most common version control systems used today is Git, and it’s also the system used to manage the

source code of both the Android Open Source Project and the Linux kernel. Git is a distributed version control

system that allows a developer to work independently from other developers. After the developer completes

the changes to the source code for a certain feature, he can push the changes to a server where the other

developers can retrieve it.

You can read more about Git and download it for various platforms at For

a deeper introduction to Git and version control, I recommend the book, Version Control with Git (see

the “Further Resources” section at the end of this chapter).

A great feature with Git is that you don’t need a server in order to use it, which makes it suitable for all types of

projects, from projects where you’re the only developer to projects consisting of multiple teams. I recommend

that you always initiate a new Git repository for every new Android application you start developing. Although

you can perform all Git operations from your IDE, it’s always good to be able to use the command-line tool as

well. The example that follows shows how to initialize a new Git repository:

$ git init <path to project directory>

Initialized empty Git repository in <path to project directory> ./git

After you set up a Git repository for your project, you can start to add and commit changes. Usually, you

perform these operations through your IDE, but if you want, you can also perform the add and commit

commands from the command line. If you’re new to Git, I recommend that you take a tutorial before you start

using it.

Git becomes really powerful when a team of developers needs to work together on the same source code. The

team should set up a remote Git repository to which all the team members can synchronize their changes. The

easiest way to do so is either to set up a gitolite server, which is dedicated server software that provides remote

access to Git repositories, or to use a ready-made hosting solution like GitHub for remote Git repositories.

Gitolite allows you to set up your own server for hosting Git repositories, as well as define fine-grained access

control. If you need full control of your source code management or aren’t able to store your source code

outside the company network, gitolite is your best choice.

You can find the documentation and download for gitolite at

An excellent quick installation guide can be found at


GitHub is a web-based hosting service for development projects that use Git. This online service provides both

a free and a paid service for individuals and businesses. The great thing about GitHub is that it provides an easy

way to share code with anyone on the Internet. If you want to be able to access your central repository when

outside the office or share your code as open source, then GitHub is a good choice.

Read more about GitHub at

Regardless of the size of your project, version control is very important. Even if you’re making only a small

prototype or test app, it’s good practice to always set up a Git repository. When you can track the history of your

code, you not only have the ability to track your changes efficiently but also the ability to understand why a

change occurred, because each commit will contain a message describing it. Take the little extra time required

to set up version control every time you start a project. Doing so will pay off.

Many developers working with software code will find one more very useful “tool” related to version control:

namely, two pairs of eyes inspecting the work, rather than just one, because developers working alone can

easily miss their own mistakes. This is why code reviewing is such a powerful technique when it comes to

improving the quality of your code. The problem with code reviewing is that it has often taken a lot of effort.

Fortunately, there are now excellent tools to support code review, and one of the best is Gerrit.

Gerrit’s two main advantages are that it integrates with Git perfectly and it’s completely web-based. Gerrit is

also the same code-review tool used for the Android Open Source Project. The basic idea with Gerrit is that a

developer pushes a change up the main repository. Before the change gets merged to the main branch, Gerrit

sends a notification to all project members that have “subscribed” for these changes, letting them know that there

is something new to review. Each reviewer can then compare the change with the previous commit and give the

change a ranking and a comment, indicating if something should be fixed or if it looks okay. If something needs

to be fixed, the original developer can push up another update that gets tracked by Gerrit. When everything looks

okay and is verified, the change can be pushed to the main branch and be available to all developers.

You can find out more about Gerrit and download the server at


When you’re working on a team with many developers, code reviewing with Gerrit is a great tool because

it supports a distributed review method. The reviewer doesn’t need to be located near the developer to ask

questions or give feedback but can do so directly in the tool. It might seem at first that this extra tool will add

unnecessary overhead to a project, but anyone who has been doing code reviewing on a regular basis knows

how much it improves the quality of the code. For an example of what the Gerrit tool looks like, see Figure 1-2.


Figure 1-2 The web interface for the Gerrit code-review tool

Mastering Your IDE

In May 2013 at the Google IO conference, Google announced a new IDE for Android named Android Studio.

This IDE is based on the open-source version of IntelliJ IDEA (Community Edition). The reason for switching

from Eclipse, which was the previously supported IDE, to IntelliJ IDEA was due to the complexity involved in

developing the Android plug-in for Eclipse. IntelliJ IDEA provided a far more superior platform for development

and allowed the Android tools team at Google to take the development experience to a new level as they could

integrate the Android tools into the IDE instead of simply providing a plug-in.

In this section, I cover three useful features that are supported by Android Studio: debugging, static code

analysis, and refactoring. Although these features have been available from both IntelliJ IDEA and Eclipse for

some time, I keep seeing many developers, both beginners and experienced developers, not using them to

their full extent. A developer who fully masters these features in his IDE will notice that he becomes much more

efficient in producing high-quality code.

Debugging Android Applications

Debugging capabilities give you fine-grained control over the execution of an application. You can set

breakpoints where execution will pause and inspect every aspect of the application state. This feature becomes

most useful when it comes to discovering the source of a bug or when you need to carefully inspect exactly

what happens during execution. The capability to debug Android applications is built into the IDEs, providing a

simple user interface for stepping through the code, inspecting variables, and even changing their values.


You can debug Android applications on your device through the Android SDK. Your IDE will connect to the

debugging Service (adb) running on your device, which in turn connects to the Dalvik virtual machine

(VM) that your application is running. The procedure is basically the same one you follow when you run an

application from your IDE.

Figure 1-3 shows one of the sample applications from the Android SDK opened in Android Studio. As you can

see, I set a break point in the code and started the debugging from my IDE. The figure shows how the IDE looks

once the execution hits the breakpoint.

Figure 1-3 Breakpoint reached when debugging sample application in Android Studio

When a breakpoint is reached, you can inspect the state of the application at that specific point. All variables

accessible in that scope are listed in the debugger UI in the IDE. While debugging applications, you can change

the value of a variable in the current scope without having to restart the application and change the assignment

in the code, which is useful for testing how an application works depending on different input values. For

instance, if your application reads input from a sensor and you are unable to control the values from this sensor,

setting a breakpoint after data from the sensor has been read can be a powerful tool during development.

Android Studio contains a very powerful debugger tool that not only allows you to change the value of

variables but also to execute arbitrary code at the current scope, as shown in Figure 1-4. This capability is

especially helpful when you’re performing more advanced inspections that require the temporary injection of

several lines of code at the breakpoint.


Figure 1-4 Executing the code evaluation tool in Android Studio

Remember that using the debugger is not a substitute for writing tests for your application.

Static Code Analysis with lint

Even the best developers make mistakes in their code, and over the years different ways of dealing with this fact

have been developed. Writing unit tests has proven to be very effective and is something I highly recommend

to all developers. However, even with carefully written unit tests, it’s hard to cover all possible situations that

might occur in the code, which is why it’s important to complement unit testing with other methods@mdfor

instance, static code analysis. Fortunately, Google has added such a tool, called lint, to the Android SDK.

The lint tool performs checks on your project’s source files, both XML and Java, and searches for missing

elements, poorly structured code, unused variables, and more. In your IDE, the results appear as highlighted areas

(see Figure 1-5) indicating that something needs to be fixed. Hovering the cursor over these highlights shows you

more details and in some cases allows you to perform the “quick fix” command in order to correct the problem.


Figure 1-5 Android Studio showing missing attributes highlighted in a XML layout file

Although it’s a very powerful tool, sometimes lint can indicate a warning in code that may be correct. A warning

could be about an unused method declaration or a missing recommended attribute in the manifest. In these

cases, the lint warnings may become irritating, especially if several developers are involved in a project. In that

case, it may be a good idea to actively suppress a warning for a specific part of the code to indicate that things

are okay, despite what lint thinks.

Suppressing lint warnings can be done for both Java and XML source files. For Java, you use the annotation @

SuppressLint with the warning you want to suppress as an argument, as shown in Figure 1-6.

In XML files, you include the lint namespace and add tools:ignore=”WarningName” (where

WarningName is the warning you want to suppress; see Figure 1-7) to the part where you want to suppress the


Remember that lint warnings are there for a purpose. They indicate areas that are potential bugs, so always

carefully consider whether you really want to suppress the warning. It’s often better to leave the warning in

place rather than remove it, as a reminder that it should be dealt with later.



Figure 1-6 Warning suppressed in Java source

Figure 1-7 Warning suppressed in XML source

Refactoring Your Code

When you write code, you rarely get it perfect on the first try. You tend to change the structure and names of

methods, variables, and classes. When the number of classes grows in a project, you might move them into a

separate package. As you write more and more code, you suddenly realize that you have code that does the

same thing written in several different places with just minor differences.

Making changes in existing code can become a complicated process when that code is referenced in many

places. If you want to add another parameter to a method, you need to find all the places where the method

is used and update those. This can become a very complicated and error-prone process if done manually.

Fortunately, your IDE has a built-in function called Refactoring that makes this task simple and eliminates

the risk of introducing any bugs.

Many refactoring tasks are available in your IDEs. Refactoring involves simple things like renaming and moving

variables, methods, classes, and packages, as well as more complex operations such as changing the signature

of methods, encapsulating fields, replacing code duplicates, and replacing inheritance with delegation. I cover

some of the most common tasks in the following sections.

To use refactoring in Android Studio, place the cursor at the position in the code where you want to change

something and then select the refactoring task from the Refactor menu.

Extracting Constants

When you write code it is easy to ignore some best practices that we all know would benefit us in the long

run. A common example is when writing constant values in the code (that is, using the actual value instead

of a variable) instead of declaring a constant variable (a variable declared as public static final). The

problem is that once you decide to change the value, you need to find all the occurrences of that value and

replace it with the constant’s name. This is where the Extract Constant refactoring task comes in. As shown

in Figure 1-8, this task allows you to quickly and correctly replace all occurrences of that value with a newly

declared constant.

Changing the Method Signature

The method signature defines the access modifier (private, protected, package local or public),

return type, name, and parameters for a method. If you have a commonly used method where you want to

add an extra parameter, making the correct change in all places where the method is used in your project can

become complicated. Figure 1-9 shows how you can change all the parts of a method signature as well as all the

places where it’s used in your code.



Figure 1-8 Extracting a repeated value to a constant in Android Studio

Figure 1-9 Changing a method signature in Android Studio


Extracting the Method from Code Block

It’s good practice to keep methods small to make code more readable and allow for more efficient reuse of

the code. When you see that a method is growing out of proportion, you can mark off a block in the code and

perform an Extract Method task as shown in Figure 1-10. After that, you can also perform the Change Method

Signature task to make the method more generic and reusable if needed.

Figure 1-10 Extracting a block of code to a separate method in Android Studio

There are many more refactoring options available in the IDE. I recommend that you become familiar with all of

these as they will make you a more productive developer. For more refactoring options in Android Studio, which

is based on IntelliJ IDEA, users can find a comprehensive guide to most of the refactoring tools at http://

Developer Options on Android Devices

In the Settings application on your Android device, you can find the Developer Menu. Depending on which

version of Android you’re running, this can present different options. Also, some device manufacturers may add

their own settings in the Developer menu. In this section, I cover the most important details of the Developer

menu in Android 4.2 on a Nexus device.


Starting with Android 4.2, Google hides the Developer menu by default, purely for security reasons: Showing

the Developer menu could create some serious security issues if it’s enabled by mistake. Here’s how you enable

the Developer options on an Android device with version 4.2 or later:

1. Go to the Settings application.

2. Scroll down the list of options and tap the About Phone option, located at the bottom of the list.

3. Locate the row with the label Build Number and tap the Build Number option seven times.

A notification saying “You’re Now a Developer” appears, and the Developer Options menu now appears in

the Settings list.

Understanding Developer Settings

In the Developer Options menu (see Figure 1-11), you will find many choices that may be confusing at first.

Although they’re all useful in certain situations, I cover those that I believe are most useful for application


Figure 1-11 The Developer Options menu on a Nexus 4

device running Android 4 .2

The first option you want to enable is Stay Awake, which causes your device to keep the screen on while it’s

charging—of course, the USB cable needs to be connected to your laptop. This way, you don’t have to unlock

your device whenever you want to deploy and run the application you’re developing, which saves a lot of


A bit further down the list is the Debugging option, which contains a number of useful options that you need

to understand. The first option you want to enable is USB Debugging. Without this option, you won’t be able

to connect the device to your development environment using the adb tool. If you’ll be working with Google

Maps or the Location API, enable Allow Mock Locations too, so that you can test different location parameters

without having to travel all over the world.

Under Input are two settings (Show Touches and Pointer Location) that you’ll find useful when writing

applications that rely on advanced touch input, such as gestures and multi-touch interfaces.

The Drawing option contains several settings options that allow you to get visual feedback on how the user

interface is laid out and how fast and often a redraw occurs. You can also set scaling parameters for animations

and transitions as well as disable them completely for debugging purposes. One setting that is new with

Android 4.2 is the possibility to simulate a secondary screen. With the introduction of multiple displays in

Android 4.2, this feature makes it easy to develop multi-screen applications without having to connect your

device to a real secondary screen. Instead, the Android system will draw an overlay on top of the standard user

interface that simulates this second display.

Under Monitoring, you find some options that can prove invaluable for ensuring that your device runs

smoothly. Most developers are usually equipped with the latest version of high-end smartphones. Normal

users, however, may use older devices with less powerful CPUs and memory. An application that runs fine on

your high-end device can become sluggish and even encounter the dreaded Application Not Responding (ANR)

message if you’re not careful. The options under Monitoring in the Development Options menu can help you

spot these problems early on. By checking Strict Mode Enabled, the screen on your device will flash when you’re

performing a long operation on the main thread. Show CPU Usage is useful for tracking how much more the

CPU is working when your application is running, which you can use for comparison with other applications

on the same device to see if you’re doing better or worse than they are. Comparing the performance of your

application with other similar and popular apps is a good practice.

In the final section, named Apps, there are three options that are also useful for simulating the behavior

of devices with less CPU and memory. The Don’t Keep Activities option makes sure that your Activities are

restarted from scratch every time they’re launched. Normal behavior for Android is to keep Activities alive for

as long as possible so that they can be launched faster. The system will completely remove (that is, destroy)

Activities only when the device runs low on memory. By checking this option, you can simulate how your app

will behave on a device with much less available memory. You can further simulate this kind of behavior by

changing the Background Process Limit option, which forces background operations to stop much earlier.

Finally, checking Show All ANRs is recommended for all developers, because it will become much more obvious

when an application crashes in the background. Normally, ANRs aren’t shown unless the current foreground

application causes it to show.


In this chapter, I covered the details of the Android SDK, some of the hidden features of the adb tool, how to

stress test your application with the Monkey tool, how to use the ProGuard tool for obfuscating your code, and

how the new build system based on Gradle works. I continued with more details on how to setup an Android

Library Project or how to integrate a third-party library for your Android application.

Because the use of Git as a Source Code Management system for software development is quite widespread

today, I also described how you can combine Git with various Services in order to make it easier for a team to

work together.

The new IDE for developing Android applications, called Android Studio, contains a number of advanced

features that many developers have rarely used. By understanding and mastering the refactoring features in this

IDE, you can simplify complex tasks when you need to re-structure your code. It also helps to simplify existing

code without the risk of introducing new bugs.

Finally, I outlined some of the more important details about the developer options settings in Android. It’s

important to have a full understanding of how these work and how they can assist in development, debugging,

and testing. Just remember to switch them all off and test your application without them to ensure that

everything works as intended on a normal user’s device.

Developing software is more than simply writing code, regardless what kind of application or service you’re

developing. For Android, mastering the tools is as important as the quality of your code, because when the tools

are used to their fullest extent, the writing of the code becomes much easier and less error prone.

Further Resources


Loeliger, Jon, and Matthew McCullough. Version Control with Git. O’Reilly Media, Inc., 2012.


Android development resources from the official Android Developer site: http://developer.

The Gradle build system: