I encountered a fun problem today… My Espresso tests started hanging after I added a ProgressDialog into my layout that was visible when the Activity started.

This was the error in the logs:

Could not launch intent Intent { act=android.intent.action.MAIN flg=0x14000000 cmp=co.blah/.ui.activity.MainActivity } within 45 seconds. Perhaps the main thread has not gone idle within a reasonable amount of time? There could be an animation or something constantly repainting the screen. Or the activity is doing network calls on creation? See the threaddump logs. For your reference the last time the event queue was idle before your activity launch request was 1476277650154 and now the last time the queue went idle was: 1476277650154. If these numbers are the same your activity might be hogging the event queue.

It was only happening on devices running Lollipop (Android 5.0, 5.1) or higher. So Marshmallow (6.0) and Nougat (7.0) as well.

Apparently the indeterminate ProgressBar animation causes Espresso to think things are still happening. And it just waits. And waits. Until it gets killed after 45 seconds. Great. This happens even though animations are turned off in the developer options.

There were a couple of workarounds I found on the internet, but I felt they had their own issues so I’ve come up with my own.

We used to have a physical server in our studio to run our Jenkins continuous integration for our Android projects, but after several machines gave up in quick succession I decided it would be cheaper and less time consuming to set one up in the cloud (we chose Digital Ocean as we already have a few virtual servers there). This means we don’t have to worry about hardware failures, our studio internet connection, or backing up (digital ocean can do that for you). One less thing to worry about!

However, this presented us with a challenge… We like to run some of our tests (connectedAndroidTest) on real devices, and you can’t really plug a usb hub into a ‘cloud’.

Solving The Problem

I solved this problem with a Raspberry Pi and an ssh tunnel.

ADB

Adb has several parts: a client, a server, and the bit that runs on the Android device.

Essentially, the adb client runs when you type ‘adb’ on the command line, this then connects to the adb daemon (over a port). The adb daemon runs in the background and is the bit that connects to the devices over usb.

Tunnel Pi

We now have a Pi in our studio that the Android devices are plugged into. The adb daemon runs on this Pi.

Whenever Jenkins wants to use the devices, it opens an ssh tunnel to the Pi, forwarding a port, so Jenkins’ adb client can connect to the Pis’ adb daemon. Once this port has been forwarded, adb works as normal. It’s actually quite simple!

Limitations

Your local internet connection. It’s gotta be fairly good. For example, it works flawlessly on a 30mb connection, but sometimes timed out over a very busy 6mb connection.

Adb isn’t available to download for the Pi, so you have to compile it yourself. You have to make sure the adb client and adb daemon are the same versions, otherwise they refuse to talk to each other.

How Do I Set This Up?

For detailed step by step instructions, including compiling adb on the Pi and what to run in your Jenkins job, I’ve written it up as a Gist…

I’ve been doing Android demo meetings for a while by pointing a webcam at a phone and hoping the automatic exposure doesn’t go wild half way through, always slightly envious of the iOS simulator that actually almost works, and the wide support for casting or airplay-ing an iPhone screen to your laptop / projector screen (which can then of course be shared very easily via Skype).

Ever since the “cast screen” settings appeared in Android 4.4 Kitkat I’ve thought that it must be possible to send your screen to a mac, but apparently that only works with a Chromecast, which of course my Mac is not, and nor can it pretend to be.