jayway/maven-android-plugin — pull request #104 by rtyley (2012-02-22 16:42:56+00:00)
Title: Capture screenshots from the Android device during integration tests

ddmlib supports capturing screenshots from your Android device, which is awesome, and this commit adds support for capturing select screenshots while running your integration tests- ie robotium-style tests that
drive your app -and additionally creates an animated gif of the resulting sequence, which for example can be pushed to your chatroom on every build to give a quick visual assessment of the state of the app.

Handling the scheduling of the screenshots is tricky, and to this end I've created a small framework to address issues around taking screenshots with ddmlib:

* ddmlib image capture is slow, around 600ms+ per image
* if the device screen is updating, the captured image is likely to show
a partially-updated framebuffer
* ddmlib is invoked on the development environment side of your setup
(ie your machine executing the Maven build) - your app code can't
easily take screenshots itself, but in order to get best screenshot
results your device screen should not be changing when the screenshot
is taken

The android-screenshot framework addresses these issues:

https://github.com/rtyley/android-screenshot-lib

Your development environment runs an OnDemandScreenshotService, using ddmlib to listen for log messages tagged 'screenshot_request'. Your app integration test code just writes one of these log messages when it wants a screenshot taken, and the service obliges by capturing an image from the device. To get the best results, your tests should then pause for a second so that the screenshot is of a static screen. That simple operation is wrapped up for convenience in this class (but you don't have to use it):

https://github.com/rtyley/android-screenshot-lib/blob/master/celebrity/src/main/java/com/github/rtyley/android/screenshot/celebrity/Screenshots.java

For the android-maven-plugin, the screenshots are written to the 'screenshots' folder under the target folder. They are organised into subfolders based on the friendly device name, so you can get a snapshot of how your app looks across several different devices very easily by just running it on a multi-device build - obviously that works with the emulator too.