Capture screenshots from the Android device during integration tests by rtyley · Pull Request #104 · simpligility/android-maven-plugin

@rtyley

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.