We wanted to move our Android device tests to a Linux host: it’s cheaper hardware, and we find that our Mac Mini build machines tend to fumble Android USB connections, making phones mysteriously vanish in the middle of a test run. We mostly use Docker containers to manage our Linux servers, and we decided to try to build an Android test container that could test with real phones, cloned once for each model/group of phones, so it would fit into the existing server scheme.
A quick sidebar: one of the benefits of running on Linux over running on Mac was that because it’s a more open system, it showed us one of the causes of the phones’ mysterious disappearance during the tests: disconnections lasting a fraction of a second. This allowed us to patch our test layer, adding a retry in the right place which has resolved pretty much all of our remaining problems in that regard. I will be encouraging my colleague to write that up shortly.
Docker is a system that combines a means of building and distributing software configurations together with an operating-system framework that keeps each ‘container’ of software isolated from the rest of the computer: separate filing system, separate process space, etc. Container processes share the same operating system instance, but the operating system is a lot more strict about who can talk to what than usual, so the overall effect is similar to a set of virtual machines.
Clarifying diagrams from Docker’s website:
A VM system runs other OSs on top of the host OS:
A Docker system runs containers on top of one OS:
We wanted each container to control its own set of phones. The most natural way of doing this was to assign each group of USB sockets to a different container - devices plugged into the computer’s front panel appear in the directory /dev/bus/usb/001, so we allow container 1 to see that directory; devices plugged into the back panel appear in /dev/bus/usb/002, so container 2 is allowed to see that directory, and we ordered an expansion card for more connections.
So far, so good, but Android’s ADB command talks to the phones through a daemon on the default port 5037 which is machine-wide, so the first container to run adb would start the adb daemon (adbd) and cause all the other containers to connect to that daemon and see the first container’s phones. This could have been solved with docker networking (each docker container gets its own IP, and hence its own set of ports), but it suited us to use a different mechanism: each container was configured with a different value of the environment variable ANDROID_ADB_SERVER_PORT. We allocated a port to each container so each container starts its own adb daemon, which can only see that container’s own phones.
While developing this, we found that we needed to be careful not to run ‘adb’ at the host-machine level without setting ANDROID_ADB_SERVER_PORT, because a host-level adbd that could see all the USB ports would ‘steal’ phones from the Docker containers: phones can only talk to one ‘adbd’ at a time.
If we were only using emulators, separate adbd processes would suffice. However, we use real devices, so…
Updating containers with hot-plugged USB devices
The second problem - and the main reason for writing this article - was that when a phone was rebooted as part of our normal build process, it vanished from the container’s file system, and hence its list of phones, and never came back!
On the host machine, you can see phones being added and removed by keeping a look at the files in /dev/bus/usb: the system creates and deletes files to match the phones:
Unfortunately, not only do these creations and deletions not happen within the Docker containers, but even if you set things up to create and delete those nodes, the nodes you create don’t actually talk to the phones!
The sledge-hammer we used to resolve this issue was putting our containers in
--privileged mode, and letting them see the whole /dev/bus/usb directory as the host machine sees it.
Now we needed a different mechanism to segregate the phones by bus. I downloaded the Android source, and trivially patched platform/system/core/adb/usb_linux.cpp
Each container was given a different ADB_DEV_BUS_USB value to denote the bus it should pay attention to.
Aside: although the patch was trivial, building abd required trial and error, because most people want to build everything. My final recipe was this (in a case-sensitive filesystem - my work laptop is a mac):
Multiplexing USB ports
So far so good, but when we installed our USB expansion card we found that there was only one USB bus on it, taking our machine to three buses, whereas we had five groups of devices we wanted to segregate.
Having been inside ADB’s source code already, I decided simply to add another environment variable: ADB_VID_PID_FILTER takes a list of vid:pid pairs, and makes adb ignore any device that doesn’t match.
The patch is below. There may be a slight race condition, when multiple adbd processes listening to the same USB bus try to scan the phones, but in practice this hasn’t proven to be a problem.
I hope all this saves you some time, if you’re engaged in a similar project. Feel free to ask for clarifications in the comments below.