Difference between revisions of "Testing Android Applications on a Physical Android Device with ADB"

Revision as of 19:29, 1 July 2013

<google>BUY_ANDROID</google>

Whilst much can be achieved by testing applications using an Android Virtual Device (AVD), there is no substitute for performing real world application testing on a physical Android device.

Communication with both AVD instances and connected Android devices is handled by the Android Debug Bridge (ADB). In this chapter we will work through the steps to configure the adb environment to enable application testing on a physical Android device with Mac OS X, Windows and Linux based systems.

An Overview of the Android Debug Bridge (ADB)

The primary purpose of the ADB is to facilitate interaction between the development system and both AVD emulators and physical Android devices for the purposes of running and debugging applications.

The ADB consists of a client, a server process running in the background on the development system and a daemon background process running in either AVDs or physical Android devices such as phones and tablets.

The ADB client can take a variety of forms. For example, a client is provided in the form of a command-line tool named adb located in the Android SDK platform-tools sub-directory. Similarly, the Eclipse ADT Plugin also has a built-in client.

A variety of tasks may be performed using the adb command-line tool. For example, a listing of currently active virtual or physical devices may be obtained using the devices command-line argument. The following command output indicates the presence of an AVD on the system but no physical devices:

$ adb devices
List of devices attached
emulator-5554   device

Enabling ADB on Android 4.2 based Devices

Before ADB can connect to an Android device, that device must first be configured to allow the connection. On phone and tablet devices running Android 4.2 or later, the steps to achieve this are as follows:

1. Open the Settings app on the device and select the About tablet or About phone option.

2. On the About screen, scroll down to the Build number field (Figure 5 1) and tap on it seven times until a message appears indicating that developer mode has been enabled.

Figure 5-1

3. Return to the main Settings screen and note the appearance of a new option titled Developer options. Select this option and locate the setting on the developer screen entitled USB debugging. Enable the checkbox next to this item as illustrated in Figure 5-2 to enable the adb debugging connection.

Figure 5-2

4. Swipe downward from the top of the screen to display the notifications panel (Figure 5 3) and note that the device is currently connected as a media device.

Figure 5-3

5. Select the media device notification entry and on the resulting panel (Figure 5 4) change the connection type to Camera (PTP).

Figure 5-4

At this point, the device is now configured to accept debugging connections from adb on the development system. All that remains is to configure the development system to detect the device when it is attached. Whilst this is a relatively straightforward process, the steps involved differ depending on whether the development system is running Windows, Mac OS X or Linux. Note that the following steps assume that the Android SDK platform-tools directory is included in the operating system PATH environment variable as described in the chapter entitled Setting up an Android Development Environment.

Mac OS X ADB Configuration

In order to configure the ADB environment on a Mac OS X system, connect the device to the computer system using a USB cable, open a terminal window and execute the following command:

android update adb

Next, restart the adb server by issuing the following commands in the terminal window:

$ adb kill-server
$ adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *

Once the server is successfully running, execute the following command to verify that the device has been detected:

$ adb devices
List of devices attached
74CE000600000001        offline

If the device is listed as offline, go to the Android device and check for the presence of the dialog shown in Figure 5 9 seeking permission to Allow USB debugging. Enable the checkbox next to the option that reads Always allow from this computer, before clicking on OK. Repeating the adb devices command should now list the device as being available:

List of devices attached
015d41d4454bf80c        device

In the event that the device is not listed, try logging out and then back in to the Mac OS X desktop and, if the problem persists, rebooting the system.

Windows ADB Configuration

The first step in configuring a Windows based development system to connect to an Android device using ADB is to install the appropriate USB drivers on the system. In the case of some devices, the Google USB Driver must be installed (a full listing of devices supported by the Google USB driver can be found online at http://developer.android.com/sdk/win-usb.html).

To install this driver, launch Eclipse and perform the following steps:

1.Launch Eclipse and open the Android SDK Manager (Window -> Android SDK Manager).

2. Scroll down to the Extras section and check the status of the Google USB Driver package to make sure that it is listed as Installed.

3. If the driver is not installed, select it and click on the Install packages button to initiate the installation.

4. Once installation is complete, close the Android SDK Manager.

For Android devices not supported by the Google USB driver, it will be necessary to download the drivers provided by the device manufacturer. A listing of drivers and download information can be obtained online at http://developer.android.com/tools/extras/oem-usb.html.

When an Android device is attached to a Windows system it is configured as a Portable Device. In order for the device to connect to ADB it must be configured as an Android ADB Composite Device. <google>ADSDAQBOX_FLOW</google> First, connect the Android device to the computer system if it is not currently connected. Next, display the Control Panel and select Device Manager. In the resulting dialog, check for a category entitled Other Devices. Unfold this category and check to see if the Android device is listed (in the case of Figure 5-5, a Nexus 7 has been detected):

Figure 5-5

Right-click on the device name and select Update Driver Software from the menu. Once the device drivers have been uninstalled, disconnect the device from the computer. Select the option to Browse my computer for driver software and in the next dialog, keep the Include subfolder option selected and click on the Browse… button. Navigate to the location into which the USB drivers were installed (in the case of the Google USB driver, this will be <sdk path>\sdk\extras\google\usb_driver) and click on OK to select the driver folder followed by Next to initiate the installation.

During the installation, a Windows Security prompt will appear seeking permission to install the driver as illustrated in Figure 5-6. When this dialog appears, click on the Install button to proceed.

Figure 5-6

Once the installation completes, the Windows driver update screen will refresh to display a message indicating that the driver has been installed and that the device is now recognized as an Android Composite ADB Interface:

Figure 5-7

Return to the Device Manager and note that the device is no longer listed under Other Devices and is now categorized as an Android Composite ADB Interface. Figure 5-8, for example, shows the device entry for a Nexus 7 tablet using the Google USB driver.

Figure 5-8

With the drivers installed and the device now being recognized as the correct device type, open a Command Prompt window and execute the following command:

adb devices

This command should output information about the connected device similar to the following:

List of devices attached
015d41d4454bf80c        offline

If the device is listed as offline, go to the device display and check for the dialog shown in Figure 5-9 seeking permission to Allow USB debugging.

Figure 5-9

Enable the checkbox next to the option that reads Always allow from this computer, before clicking on OK. Repeating the adb devices command should now list the device as being ready:

List of devices attached
015d41d4454bf80c        device

In the event that the device is not listed, execute the following commands to restart the ADB server:

adb kill-server
adb start-server

In the event that the device is still not listed, try executing the following command:

android update adb

Note that it may also be necessary to reboot the system.

Linux adb Configuration

For the purposes of this chapter, we will once again use Ubuntu Linux as a reference example in terms of configuring adb on Linux to connect to a physical Android device for application testing.

Begin by attaching the Android device to a USB port on the Ubuntu Linux system. Once connected, open a Terminal window and execute the Linux lsusb command to list currently available USB devices:

~$ lsusb
Bus 001 Device 003: ID 18d1:4e44 asus Nexus 7 [9999]
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Each USB devices detected on the system will be listed along with a vendor ID and product ID. A list of vendor IDs can be found online at http://developer.android.com/tools/device.html#VendorIds. The above output shows that a Google Nexus 7 device has been detected. Make a note of the vendor and product ID numbers displayed for your particular device (in the above case these are 18D1 and 4E44 respectively).

Use the sudo command to edit the 51-android.rules file located in the /etc/udev/rules.d directory. For example:

sudo gedit  /etc/udev/rules.d/51-android.rules

Within the editor, add the appropriate entry for the Android device, replacing <vendor_id> and <product_id> with the vendor and product IDs returned previously by the lsusb command:

SUBSYSTEM=="usb", ATTR{idVendor}=="<vendor_id>", ATTRS{idProduct}=="<product_id>", MODE="0660", OWNER="root", GROUP="androidadb", SYMLINK+="android%n"

Once the entry has been added, save the file and exit from the editor.

Next, use an editor to modify (or create if it does not yet exist) the adb_usb.ini file:

gedit  ~/.android/adb_usb.ini

Once the file is loaded into the editor, add the following lines (once again replacing <vendor_id> and <product_id> with the vendor and product IDs returned previously by the lsusb command) before saving the file and exiting:

0x<vendor_id>
0x<product_id>

Using the above syntax, the entries for the Nexus 7 would, for example, read:

0x18d1
0x4e44

The final task is to create the androidadb user group and add your user account to it. To achieve this, execute the following commands making sure to replace <user name> with your Ubuntu user account name:

sudo addgroup --system androidadb
sudo adduser <username> androidadb

Once the above changes have been made, reboot the Ubuntu system. Once the system has restarted, open a Terminal window, start the adb server and check the list of attached devices:

$ adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
$ adb devices
List of devices attached
015d41d4454bf80c        offline

If the device is listed as offline, go to the Android device and check for the dialog shown in Figure 5 9 seeking permission to Allow USB debugging.

Testing the adb Connection

Assuming that the adb configuration has been successful on your chosen development platform, the next step is to try running the test application created in the chapter entitled Creating an Example Android Application on the device itself.

Launch Eclipse, right-click on the AndroidTest entry in the left hand panel and select Run As -> Android Application. If the Android device is connected and detected by adb, the application should load and run on the device instead of within the emulator. Output on the console panel should read as follows as the application is loaded. If the console panel is not present in the Eclipse IDE window, it can be displayed by selecting the Window -> Show View -> Console menu option:

[2013-06-11 15:24:40 - AndroidTest] Performing com.example.AndroidTest.AndroidTestActivity activity launch
[2013-06-11 15:24:43 - ] Uploading AndroidTest.apk onto device '015d41d4454bf80c'
[2013-06-11 15:24:43 - AndroidTest] Installing AndroidTest.apk...
[2013-06-11 15:24:45 - AndroidTest] Success!
[2013-06-11 15:24:45 - AndroidTest] Starting activity com.example.AndroidTest.AndroidTestActivity on device 015d41d4454bf80c
[2013-06-11 15:24:45 - AndroidTest] ActivityManager: Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.AndroidTest/.AndroidTestActivity }

Note that the Console panel has a number of modes consisting of Android, DDMS and OpenGL Trace View. If no output is displayed in the console it may be that it is not currently in Android mode. To change the mode, click on the console toolbar button as illustrated in Figure 5 10 and select Android from the drop down menu.

Figure 5-10

Manual Selection of the Application Run Target

By default, Eclipse and the Android ADT Plug-in are configured to automatically choose the run target for application testing. This means that when a physical Android device is attached to the system and visible to adb, the application will run on the device. In the event that the device is not connected, however, the default is to run within the emulator.

It is possible, however, to configure the environment to prompt you for the target each time the application is launched from within Eclipse. To configure this, right-click on the application name (in this case AndroidTest) in the right hand panel and select the Run As -> Run Configurations… menu option. Within the Run Configurations dialog, select the Target tab and change the Deployment Target Selection Mode to Always prompt to pick device as illustrated in Figure 5 11:

Figure 5-11

Click on the Apply button and then close the dialog. On future application launches, the Android Device Chooser window shown in Figure 5-12 will appear providing the choice between running within the emulator or on a connected physical Android device:

Figure 5-12

Summary

Whilst the Android Virtual Device emulator provides an excellent testing environment, it is important to keep in mind that there is no real substitute for making sure an application functions correctly on a physical Android device. This, after all, is where the application will be used in the real world.

By default, however, the Eclipse and Android ADT environments are not configured to detect Android devices as a target testing device. It is necessary, therefore, to perform some steps in order to be able to load applications directly onto an Android device from within the Android development environment. The exact steps to achieve this goal differ depending on the development platform being used. In this chapter, we have covered those steps for Linux, Mac OS X and Windows based platforms.

<google>BUY_ANDROID</google>