Use Better Screenshot Means

[JakeWharton]

...to get awesome full-screen screenshots.

Socket to the host which captures using normal means through ddmlib. Could be a simple REST API or just dumb text communication. Client would block until a response was received. Fall back to decor view.

[JakeWharton]

Root detection added in jw/root branch.

[edenman]

Alternatively, try to use this: http://code.google.com/p/android-screenshot-library/ then we wouldn't need root!

[brnhffmnn]

Just thinking out loud: Would it be possible to take the screenshots via ddms? Somehow the instrumenation app would need to send a command up to the runner, so it could invoke IDevice.getScreenshot.

[JakeWharton]

The test would also have to block until the screenshot was taken which is the harder problem.

[brnhffmnn]

I managed to get DDMS take screenshots. Tests are also blocking until the screenshot is taken.

I hooked up android-screenshot-lib (not the same as the one on google code). Basically it listens for logs with a special tag. To get the test to block, a file will be created on the device which gets deleted via adb. As soon as the file is gone the test continues. Root is obviously not needed on the device.

I didn't request a pull yet, because it's not fully tested yet (+I didn't write tests) and there is still one issue: screenshots appear to be duplicated in the resulting report. But I didn't find the cause yet. Also the screenshots are not rotated with respect to the current device orientation, but I actually don't mind that.

May I ask for a review? See my screenshot-ddms branch

[JakeWharton]

@panzerfahrer We explicitly avoided going that route since it's very fragile and the blocking is awkward. You may have noticed that the library is where we stole the animated GIF creation from, however.

One way we were going to approach it was to start a web server on the desktop and use adb to port forward it to all of the devices. This way the Spoon.screenshot method could make a synchronous HTTP connection with the tag and test info and wait for the response.

The other would be to use a native service deployed via adb on test run which allows taking full screen captures on the device and then pulling at the end in the normal fashion.

For something like what you describe to be added we definitely would need things like proper orientation support. I'll try to take a look at what you have tonight.

[RichardGuion]

I am following this issue as I would like to see dialogs in the screenshots. I am using Robotium in addition to Spoon, when I used their solo.takeScreenshot method it captured the dialog fine. However, it just captured the view for the dialog and not the entire screen. You probably don't like that approach as it would mess up the animated gif.

[JakeWharton]

Correct. We also don't want to depend on Robotium!

We'll likely go the route of starting a native service over ADB and use it to take screenshots of the entire screen (including the status bar and soft buttons, woot).

[JakeWharton]

Started work on the jw/full-screen-capture branch. The idea is that the runner deploys a binary that listens on a port for connections and a full path to the target image. The server captures the framebuffer and encodes it to a PNG at the destination file. If any exceptions are encountered they are sent back along the socket connection, otherwise it is simply closed.

AOSP has two on-device binaries for capturing the framebuffer screencap and screenshot. Both have dependencies on internal AOSP things which we probably want to tear out into a standalone tool. We also would need to get compilation working for all architectures and have detection (using #76) to deploy the correct binary. I'm fairly certain the maven-android-plugin supports this but we'd have to figure out how to bundle the results as part of the final runner jar.

We also need an effective way of not starting duplicate servers and killing the server once execution has completed. A simple PID file should suffice.

I don't have the time to work on this now. Maybe in 4-6 weeks.

[brnhffmnn]

After my first attempt with the quirky "lock file" approach, I tried it with running a server on the device.

I'm starting a server within the InstrumentationTestRunner. spoon-runner houses a client which connects to the server via an ADB port forwarding. I'm not using a native service, but plain Java socket channels.

Unfortunately, it's not really working and I couldn't yet figure out what I'm missing. Anyhow, maybe it can be of help. I had to postpone my work on this, so I'm not sure when can get a look into it again.

panzerfahrer/screenshot-ddms-socket

[JakeWharton]

@panzerfahrer That's the route we initially wanted to go as well. Haven't really had time to explore it. If I get back around to work on it before you do I will definitely take a look. Thanks!