Android on Chrome OS: Pondering adb

UPDATE: We now have official adb access instructions, though those instructions have bugs. This blog post outlines what worked for me. I am leaving the rest of this post here intact for historical purposes. Or possibly for hysterical porpoises.

This week, I will be blogging about how to test your app and what sorts of problems you may run into. Monday, I described how to get Android app support on a developer preview Chromebook. Yesterday, I described how to side-load Android apps on a Chrome OS device.

Side-loading is better than nothing. Unfortunately, “nothing” is pretty close to the current state of affairs with respect to adb access. Eventually, perhaps, maybe, we will be able to connect our development machines to Chrome OS devices for the same sorts of app development tasks that we do with regular Android devices. After all, Google’s own Compatibility Definition Document stipulates that adb support is required, and since they are requiring this of other manufacturers, it would be rather nice if they honored their own requirements.

If you want to try to hack in adb support, here is what I can tell you:

What originally worked, when I first got Android support going on the Flip, was adb access on the Flip itself:

• Press ^Ctrl-Alt-T^ to bring up a window that contains crosh, a terminal emulator available on Chrome OS in developer mode

• In the crosh terminal, run the shell command to switch to a full Linux-style bash shell

• In bash, run adb connect 192.168.254.2

This is the same adb connect command that you can try to use to debug a device over TCP/IP (e.g., via WiFi). In this case, we appear to be connecting to a private network inside the Chrome OS environment itself, perhaps as part of the separation between Chrome OS and the Android worlds.

At that point, adb devices in the Flip’s bash shell showed a device, adb logcat dumped the log, and so forth.

However, after another update to Chrome OS, this no longer seems to work, as the adb connect command fails. I have not identified another IP address that works.

If you are able to get adb connect to work, the next step would be to allow adb clients from a development machine to work. What worked — somewhat, anyway — was:

• On the Chrome OS device, run the following command to open port 5037 in the device’s firewall:

sudo iptables -I INPUT -p tcp --dport 5037 -j ACCEPT

• On the Chrome OS device, kill the running adb daemon, if you have it running from earlier, via adb kill-server

• On the Chrome OS device, start the adb daemon with the -a switch (e.g., adb -a fork-server server &), as -a indicates to listen on all available IP interfaces

• On your development machine, use the -H switch with all adb commands to be directed to the Chrome OS device (e.g., adb -H ... shell, where ... is the IP address of the Chrome OS device)

However, this requires that the adb binaries on both environments be compatible. If you are up to date with your development tools, you may have a far newer adb on your development machine than you do on the Chrome OS device. That will result in an error like adb server version (32) doesn't match this client (36); killing....

Plus, all this does is allow you to run adb commands (with -H) from your development machine. It still does not allow Android Studio or other tools to work, as they will not be trying to use some -H switch.

Beyond those issues, the fact that this requires opening a port for arbitrary access is moderately scary. You should be able to craft an iptables command that limits inbound connections (e.g., your local WiFi LAN segment)… but this all gets into a level of hackery that is ridiculous, for something that should be available much more directly.

Most likely, somebody with greater command-line Linux skills than I have will work out a recipe to allow adb connect to work from your development machine, bridging into the Android container inside the Chrome OS device. And, with luck, this will become simpler, via official support, in the future.