How to use your Android phone with ADB in an Incus container – Mi blog lah!

Incus is a manager for virtual machines and system containers.

A system container (therein container) is an instance of an operating system that also runs on a computer, along with the main operating system. A system container uses, instead, security primitives of the Linux kernel for the separation from the main operating system. You can think of system containers as software virtual machines.

In this post we are going to see how to conveniently let an Incus container to have access to the Android USB debugging (ADB) of our Android mobile phone. Normally, you would run adb commands on the host. But in this case, we are launching a container and give it access to ADB. We set it up so that only the container can access the phone with ADB.

The reason why I am writing this post is that there are several pitfalls along the way. Let’s figure out how it all works.

Setting up the Android phone for USB Debugging

To enable USB debugging on your Android phone, there’s a hidden list of steps that involves going into your phone settings, tapping seven times on the appropriate place of the About page, and then your phone shows the message You are now a developer. You will need to search for the exact steps for your device, as the place where you need to tap seven times may be different among manufacturers.

Still on the phone, you then need to visit another location in the phone Settings, one that is called Developer options. In there, you need to scroll a bit until you see the option USB debugging. You will need to enable that. When you click to enable, you will be presented with a warning dialog box about the ramifications of having enabled the USB debugging. Read that carefully, and enable USB debugging. Note that after this exercise, and if you do not need to use ADB for a long period, you should disable the Developer options. The risk with the enabled USB debugging is that if you connect your phone with a (data) USB cable to some malicious computer or even a malicious USB charger, they may take over your device in a very bad way.

In the first screenshot it shows the warning when you try to enable USB debugging. The second screenshot shows that the USB debugging has been enabled successfully.

There’s an option in the second screenshot to Revoke USB debugging authorizations. I recommend to do that, especially if you have already connected your phone to your computer. By doing so, we can make sure that the host is not able to connect successfully to the device, and only the container can do so. Note that when you try to connect to the device with adb, you get a dialog box on the phone on whether to authorize this new connection.

When you connect your Android phone to your Linux host, the device should appear in the output of lsusb (list USB devices) as follows. I think the USB Vendor and Product IDs should be the same, 0x18d1 and 0x4ee7 respectively. And it should say at the end “(charging + debug)“. If you get something else, then you fell for the Android notification that says Use USB for [File Transfer / Android Auto]. That’s not good for us that we need USB debugging. The proper setting is Use USB for [No data transfer]. Yeah, a bit counter-intuitive.

$ lsusb
...
Bus 005 Device 005: ID 18d1:4ee7 Google Inc. Nexus/Pixel Device (charging + debug)
...
$ 

Setting up the host

In order to let the container have access to the phone, we need to make sure that there is no adb command on the host that is running. We can make sure that this is the case, if we run the following. If the ADB server is running on the host, then the container does not have access to the device. Interestingly, if you setup the container properly and ADB is running on the host, then as soon as you adb kill-server on the host, the container immediately has access to the device.

sudo adb kill-server

Creating the container

We are creating the container, we will called it adb, and it has access to USB debugging on the Android phone. The way we work with Incus is that we create a container with the task of accessing the phone, and then keep that container whenever we need to access the phone. In the incus config device command, we add to the adb container a device called adb(can use any name here), which is of type usb, and has the vendor and product IDs shown below. Finally, we restart the container.

$ incus launch images:debian/12/cloud adb
Launching adb
$ incus config device add adb adb usb vendorid=18d1 productid=4ee7
Device adb added to adb
user@user-desktop:~$ incus exec adb -- apt install -y adb
...
$ incus restart adb
$ 

Using adb in the Incus container

Let’s run adb devices in the container. You will most likely get unauthorized. When you run this command, your phone will prompt you whether you want to authorize this access. You should select to authorize the access.

$ incus exec adb -- adb devices
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
42282370	unauthorized
$ 

Now, run again the command.

$ incus exec adb -- adb devices
List of devices attached
42282370	device
$ 

And that’s it.

Stress testing adb in the Incus container

You would like to make this setup as robust as possible. One step is to remove the adb binary from the host.

Another test is to restart the container, and then check whether it still has access to the device.

$ incus restart adb
$ incus exec adb -- adb devices
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
42282370	device

$ incus restart adb
$ incus exec adb -- adb devices
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
42282370	device
$ 

Obviously, when you want to perform more work with adb, you can just get a shell into the container.

$ incus exec adb -- sudo --login --user debian
debian@adb:~$ adb devices
List of devices attached
42285120	device

debian@adb:~$ adb shell
komodo:/ $ exit
debian@adb:~$ logout
$ 

Conclusion

If you setup your system so that only a designated container can have access to your Android phone with USB debugging, then you get a bit better setup in terms of security.