This article builds on the concepts introduced in my previous article in this series, Using the Android Emulator and Developer Tools to Build Bullet-Proof Android Applications, Part 1. If you have not read this article, please read it first before moving on to this one.
If you've created any Android apps, you know how important testing is. Ineffective testing leads to bad ratings and poor rankings on the Android market. Mobile application development (especially for Android) is often more difficult than other types of programming (i.e., web applications).
While the Android operating system is the same on each device, the device manufacturer varies, making it difficult to effectively test for all Android devices and platforms. Each manufacturer often includes its own libraries and resource locations. For example, some manufacturers store user contact information to native storage differently from other manufacturers (i.e., Motorola vs. Samsung).
As a developer, what can you do to effectively test your applications for all the different device platforms? One tool, the Android emulator, can effectively do this, provided you use the different device profiles that come with the emulator (or custom profiles you create).
Android Emulator in Action
While the emulator has some limitations, these limitations apply to only certain types of applications. For example, at the time of this writing, the emulator does not support voice input. If you check the details for an emulator profile, it says that voice input is supported, but that is not the case as of the API level 17 SDK.
Although the device camera on an emulator is not a limitation, it is difficult to get working nonetheless. The emulator is sophisticated, but it has a lot of room for improvement, which means better apps for consumers. Finding an Android app that is 100% solid functioning (with no Force Close messages) is not likely. Often, consumers find the opposite, or worse yet, get used to having an app "force closing." The background management by the Android OS for application life-cycles is complicated, and as such, is more prone to error.
Some of the neat things the emulator can do help with is common to many applications: the capability to send and receive text messages or monitor phone calls and email.
Sending an SMS from One Emulator to Another
Sending an SMS between emulators is surprisingly simple. All you have to do is start up two instances of an emulator. Once both emulators are running, choose one emulator as the message sender and designate the other as the message receiver. On the source (sending) emulator, bring up the Contacts application.
Once this app is up, add a contact for the other emulator. Fill in a name for the "contact emulator" and give it the phone number of the port the receiving emulator is running on. For example, the default for an emulator instance starts at port 5554 on your computer. Another instance that runs at the same time often uses another port close in succession, such as port 5556. The phone number for the receiving emulator, then, is simply '5556'.
Once the contact has been created, bring up the contact details and click the message icon to type a text message. Once the message is typed, click Send; in a second or two, you will see the message flash on the receiving emulator with the source emulator phone number as the sending contact!
Making a Phone Call Between Emulators
Making a phone call is similar to texting and just as simple. Now that you already have a contact created for the receiving emulator, simply bring the phone application on the sending emulator and dial the receiving emulator's port number (5556). Or you can just use a contact that has this number. Once you call, the other emulator will start ringing with a default ringtone. You are prompted to answer or ignore, just like using the real device. If you answer, there is no input communication (voice data) that can occur between the devices at this time (no voice input is supported).
Using the Emulator Command Line
For more fine-grained debugging and tweaking of an emulator instance, a tool called the adb (Android Debugging Bridge) command line is available as part of the Android SDK. You can find the adb tool in <sdk>/platform-tools/. The adb acts as a "middle man" between the emulator-simulated image hardware and development.
The following sections list common commands that you can invoke with adb.
To target an emulator instance, simply use the following command format:
adb -s emulator-5556 <command> <-options>
To direct the instance to the only connected USB device (i.e., your Android phone), use the following:
adb -t <command> <-options>
To view a detailed buffer of system device log information and application debugging output statements, you can simply type adb logcat to start this process. The output of this process is the same output that is shown with the Eclipse IDE Logcat tab for the Android SDK. You could use this tab for one emulator instance and the command line for the other, thus monitoring debugging output for both devices at the same time.
To store the debug contents to a file for later viewing, follow these steps:
- Type adb logcat > /sdcard/adblogcat.txt
- Run the app that you want to debug on the phone.
- When done, press Ctrl + C.
- Type adb pull /sdcard/adblogcat.txt C:\adblogcat.txt
To learn about more options for the logcat command, visit http://developer.android.com/tools/help/logcat.html
Other adb Commands
Other adb commands are as follows:
- adb devices: Lists all the currently attached/running devices
- adb push: Sends files to your phone/emulator (c:\example.apk /sdcard/example.apk)
- adb pull:Receives files from your phone/emulator (/system/app/example.apk c:\example.apk)
- adb install: Installs application (c:\example.apk)
- adb shell: Begins shell connection with phone/emulator
- adb reboot: Reboots phone/emulator
- adb reboot recovery: Reboots phone/emulator into recovery
- adb remount: Remounts file system, useful for file permissions
- adb shell: Starts a command shell
- cd: Changes directories (cd /system/app)
- ls: Lists all files in the directory (ls /system/app)
- rm: Removes files (rm /system/app/example.apk)
- cp: Copies files; similar to cat (cp /system/app/example.apk /sdcard/example.apk)
- cat: Copies files (cat /system/app/example.apk > /sdcard/example.apk)
If you have worked with Linux/Unix, you'll note that the most recent commands in the list are common to any Unix shell:
- list features: Lists features on the system
- list users: Lists users on the system
- list packages: Lists packages on system
- exit: Exits shell
Accessing the SQLite 3 Database
You can also access the SQLite database from the command line. To do this, simply type out the path to your application's db file:
adb -s emulator-5554 shell # sqlite3 /data/data/<package>/databases/<db name>
Once you hit Enter, you will be at the SQLite command prompt. From this prompt, you can run SQL queries against your database. It is very handy to have this open while working on your app so you can view the data and structures of your db without hesitation.
Another developer tool Google provides is referred to as the "Exerciser Monkey." As the name suggests, the program gives your app a workout, although without a lot of intelligence behind this. From the shell, you can launch the Monkey program:
adb shell monkey -v -p your.package.name 500
Once launched, the program will generate random qevents (in this case 500) to test your application against. There are numerous options you can set, including which package(s) the program should target, what type of events should be cast, and so on. If you're serious about giving your app the best round-about testing possible, using this tool should also be in your war chest.
To learn about using the adb commands, visit http://developer.android.com/tools/help/adb.html
To learn more about using the Exercise Monkey program, go to http://developer.android.com/tools/help/monkey.html
This concludes part 2 of this article series. You learned how to use the Android emulator and the emulator command line. Try some of these commands and emulator techniques with your own current and future apps to provide the best user experience.
There is still a lot more to cover with Android testing, and in a later article, I'll show you how to use the Android Developer Options application that comes with newer phones/SDKs.