Capture screenshots from the Android device during integration tests by rtyley · Pull Request #104 · simpligility/android-maven-plugin
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.