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
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
croshterminal, run the
shellcommand to switch to a full Linux-style
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
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,
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
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
adbdaemon, if you have it running from earlier, via
On the Chrome OS device, start the
adbdaemon with the
adb -a fork-server server &), as
-aindicates to listen on all available IP interfaces
On your development machine, use the
-Hswitch with all
adbcommands 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
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
Beyond those issues, the fact that this requires opening a port
for arbitrary access is moderately scary. You should be able to craft
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.
Learn second-generation Android app development — with Kotlin and the Android Jetpack — through CommonsWare’s Android app development training!