Thwacked.

Let’s say you’re working on ironing out that pesky HTC menu issue in your app, and you’d like to know if you’ve succeeded in embracing a life without a menu button. Hard to imagine a better way than verifying on a pile of un-rooted, real devices. To get started, simply upload your app and click the device drop-down. At the bottom you’ll see an entry for selecting devices from a list.

Once selected, you’ll see a dialog containing all of the available devices. In this case we want all HTC devices so we simply filter for HTC and select them all.

We might want to use this selection again, so let’s give it a name so it’ll be available in the future. If you don’t give it a name, that’s fine; the pool will be treated as a temporary pool and not saved for future test runs. Also of note, if you have other users on your projects they’ll have access to the pools you create.

That’s it! Your app will be tested on the selected devices.

Default Pools

You’ll notice a few built-in pools along with some dynamically created ones that appear under certain circumstances. Built-in pools include “All Devices,” which includes every device available with your current plan, followed by “Top 10″ and “Top 25″ if your plan is on a higher tier.

Dynamic pools provide a pool of all devices used in the previous run, assuming there is one in your project, along with a pool containing just the devices that had test failures, again assuming there were failures in the previous run. This makes reproducing and debugging bugs and the subsequent testing of fixes straightforward.

Conclusion

Device pools provide a very effective way to do focused testing between incremental changes in your app. It’s also handy to build pools of devices that correspond to your development cycle, such as smoke and regression. Try it out and let us know what you think, either in the comments or on our support page.

We put a lot of time and thought into how your Android and web apps’ AppThwack results are formatted in our reports. The goal is to summarize hundreds of devices worth of data into a clear format while still allowing you to quickly drill down and get the nitty-gritty details. We also know that sometimes you want to process or organize your results in a certain way. For instance, you might want to grep all of your logs for a specific message or build a custom report for a client containing every screenshot. Our new download feature makes what was before an admittedly difficult task extremely easy.

As soon as the test run is complete you can download an archive containing all logs and screenshots broken down by device. It’s also possible to download the log for a specific device and test from the log viewer.

You can still share an AppThwack report by clicking Share and sending the direct link. Between sharing and exporting results, you’re now able to conduct your own analysis on your Android or web app’s results, as well as get the information to those that need it.

With the explosion in popularity of affordable phones like the Samsung Galaxy Y, Android app performance management and tracking has become even more important. Many of these devices have lower-powered CPUs and limited memory. Regardless of the device, excessive CPU usage leads to battery drain, a sluggish user experience, and eventually irate customers. Lax memory management can lead to out-of-memory exceptions, especially on the aforementioned lower-end devices.

To get into the details of memory management for Android applications, I’ll direct you to Dianne Hockburn (An engineer at Google), who has an excellent answer over on StackOverflow, and Jonathan Norén, who has his own in-depth write-up on his blog. It’s fairly straightforward to gather performance data via adb by using standard utils like procfs for CPU and thread counts and dumpsys ( adb dumpsys meminfo [your package name] ) to get memory data, but interpreting the information and collecting it at the right time can be difficult.

We had a long-standing idea to implement a handy way to track and visualize CPU usage, memory usage, thread counts, and other data, and a few weeks ago we finally sat down and hammered it out. If you’ve run tests since the beginning of January you may have noticed some new charts popping up here and there. Now that the kinks are worked out, let’s explain what that data means and how it can help.

First, an example

Let’s say you see an out-of-memory error in your high-level results.

You then click on the log link to go to the details for that specific test and device.

At the top of the log you’ll see performance data gathered during the duration of the test. Uh oh! Take a look at that spike in thread count. With this extra bit of info, you can now look at the logs, correlate the stack trace to your code and figure out where and why things spun out of control.

Tracking performance data on the test, run, and project level

In our example above, we looked at the performance data for a specific test on a specific device. This is great for isolating specific issues, but what about trending problems?

AppThwack now gathers performance data per device and per test, and we display a summary of those results on the run highlights view. There you can see the CPU, memory, and thread data charted on a scatterplot where each point is a different device, as well as the best (min) and worst (max) devices in each performance category.

Finally, we track performance data on the project level, allowing you to quickly identify emerging trends in performance. The project overview page now contains trends for overall test results (Pass, Warning, Fail), as well as averages, minimums, and maximums for overall CPU usage, memory usage, and thread counts for the past few builds. This makes it really easy to notice a change in, say, memory usage from one build to the next.

What are we tracking and what’s next?

We currently track the percentage of CPU your application is using, how much memory your app is using expressed as PSS (Proportional Set Size – See this excellent article on why PSS is useful), and the number of threads within your process. If there’s a specific piece of data  or trend you’d like to see let us know, either in the comments or on the AppThwack support page. Happy testing!

One often-requested feature we’ve heard loud and clear at AppThwack is the ability to publish reports so others can view them without logging in. Maybe you’d like to share the report with a teammate, a boss, or just brag about your results on G+ or Twitter. We’re happy to announce it’s now super easy to mark a report as public and start sharing.

When viewing a run you’ll see a slight shift in the interface and a new “Share” button.

Clicking it will bring up a small window where you can toggle the public availability of the report. Once shared, a link is generated that you can then send it to anyone you’d like.

Visiting that link allows for full navigation of the report (Don’t worry, nothing beyond the specifically shared report is accessible). This means no more copy+pasting results or requiring others to sign up just to see a report.

To unshare, simply bring up the window again and click “Unshare.”

Enjoy, and as always let us know how we can continue to improve by sending us email or submitting/voting on issues on our support page.

Since the beginning AppThwack has always launched an app and taken screenshots in portrait and landscape. Until now this meant seeing a splash screen, loading screen, or a home screen that although useful, was admittedly limited.

Today we’re excited to announce a new feature that allows the capture of screenshots at any time on any screen. The latest version (3.3) of Robotium introduced a useful new method, takeScreenshot, that simply captures a screenshot and stores it to the SD card. We’ve taken this cool feature to a new level by integrating Robotium screenshots into AppThwack’s results view.

Simply make a call to takeScreenshot in your Robotium test to have it appear in your AppThwack report. It’s super easy and with AppThwack’s help even easier to view the results than if you were to use Robotium alone.

Just like other AppThwack screenshots they are clickable and bring up full-size, pixel-to-pixel images. They are also displayed in our high level screenshots view so you can see every screenshot in one place. Enjoy!