One noteworthy point is that you won't have an adb daemon running on your VM client, except for when you're actually using the debug bridge, of course. Otherwise you should see your device and be able to logcat all day. If you see "daemon not running," it means your port fowarding is screwed up. For this reason, consider simple port fowarding over ssh (maybe via Cygwin) like so from the VM client: autossh -nNL5037:localhost:5037 -oExitOnForwardFailure=yes 10.0.2.2įinally, run adb devices from your VM client. If you're like me, you'll find the ADBHOST and ANDROID_ADB_SERVER_PORT variables to be poorly documented and easy to screw up. Now you must either forward the ports from your host to your VM client, or otherwise connect ADB directly to your host IP:port. You can check this from the VM client by running telnet 10.0.2.2 5037, where 10.0.2.2 is the default IP for VirtualBox hosts and 5037 is the default ADB port noted above.
starting it now on port 5037 *Īt this point, your host should have an ADB server running at port 5037. It should look something like this (note the port number and sorry for the mangling): * daemon not running. If all goes well (and it should), you'll see your device listed. Don't skip this step.įrom the host, execute adb devices. If you have any running instances of Eclipse, you'll want to shut those down first because it'll actually launch adb in the background. From your VM client, run adb kill-server.Don't allow your VM client to take ownership of the Android device, so disable any VirtualBox USB filter rules you have and it also wouldn't hurt to then detach and reattach the device.You should only require the platform-tools package which includes adb.
0 kommentar(er)
