· 4 min read Posted by Touchlab
Basic Android Testing
I wouldn’t really call this a “blog post” as much as a quick set of instructions for basic testing. I need to share them with somebody, so why not everybody?
Goals
If you’re testing an app, how do you get the developer the info they need? That’s basically the goal here.
The developer really needs as much info as possible, but there’s some thats more valuable than others, and is often easier to get, so we’ll cover that, and maybe throw out some ideas as to what else is useful.
Logs
Logs are by far the most obvious and useful thing to grab. Assuming the developer doesn’t eat exceptions (you don’t do that, do you?), the stack trace of what happened should be right there in the log. Also, if the developer does a reasonable job of logging, you might have some context info.
To get logs, you should have the Android SDK installed, with eclipse open. Make sure the device is plugged into USB, and open the Logcat view. Even if the error happened without being plugged in, you should be able to get some recent log data.
You can leave it up to the developer to figure out the log, but over time you should come to recognize what a stack trace looks like, and find the one associated with the app you’re testing (sometimes different apps will have a coincidentally timed exception in the log).
Screenshots
If the error is visual, a screenshot will usually help. Some phones can take a screenshot on their own. For example, the Galaxy Nexus lets you take a screenshot by pressing the down volume and power buttons at the same time.
You can also take a screenshot with the Android SDK and eclipse. I will let you search google for that.
What you were doing
Just a good, solid description of what you were doing at the time, and possibly some special circumstances. ”Geo tag not working” is a lot more interesting if you mention it was on a tablet without GPS (or whatever).
Crash Types
Very critical info. On Android, there are basically 2 types of crashes: Exceptions and ANRs (Application Not Responding)
Normal crashes are uncaught exceptions. These will produce a nice stack trace in the log, and often point at a very specific bug.
Application Not Responding, or ANR, happens when you tie up the main thread for longer than 5 seconds (the rules are a little more complex than this, but we’ll leave it there). Basically, there’s one thread that handles user input events. If you’re doing something that takes a while in code, you should do it in a different thread, so the user can still interact with the app. You *should* be showing a waiting icon or dialog (or whatever), but not “freezing” the screen. You’ll get an ANR if you freeze up the UI.
ANRs don’t show anything useful in the log, which makes them tricky to spot. They do, however, dump a file that tells you what was last running. The first step to getting the info is figuring which type you have. THIS IS VERY SIMPLE. Both error types will show you a crash dialog box. Forget what the boxes say in the message. Look at the buttons.
IF THE DIALOG HAS A “WAIT” BUTTON, ITS AN ANR. IF IT DOESN’T, ITS NOT.
To help remember, “wait” is talking about time, and ANR’s happen because you took too long doing something. Simple.
If you have an ANR, the log isn’t going to be that useful, because it doesn’t tell you where it was being held up (unless you happen to be logging something in that code, but its still indirect). However, you can grab the file “/data/anr/traces.txt” from the device’s file system. This tells you what threads were running and where you killed it. This is absolutely critical stuff.
Crash Reporting
There are a number of crash reporting products out for Android (and iOS, and whatever else). The only one I’ve used extensively is Bugsense, but they’re all pretty similar. Set it up to catch unhandled exceptions. See them in the web portal. Done. Once you deploy to Google Play, you can see errors there too. If you aren’t using any of these, you should start now.
When we get our act together, we built something a little more heavyweight, targeted more at beta testing than production. You’ll actually get logs leading up to the crash, the crash, and at the moment of crash, you can add files and possibly a screenshot. It works now, although the documentation is light, and the web panel needs some navigational tweaks. If you’d like to give it a shot, get in touch.