Android 使用模拟器远程调试

最新推荐文章于 2025-10-13 22:59:43 发布

转载最新推荐文章于 2025-10-13 22:59:43 发布 · 1.9k 阅读

标签

#android #windows #server #download #logging

Android 专栏收录该内容

254 篇文章

订阅专栏

本文介绍了解决Windows环境下ADB无法直接连接到运行在虚拟机上的Android Emulator的问题，通过设置WinSSHD、打开防火墙端口、创建虚拟账号及配置PuTTY进行远程端口转发，实现了ADB设备的正常识别与操作。

方法1

By hheimbuerger

Here is how I solved it on Windows. I pretty much followed Christopher's lead, but I can't edit, so a new answer will have to do.

The problem I had was that ADB as well as the emulator was just listening on 127.0.0.1, not 0.0.0.0, for me. Otherwise I would have usedTCPMon. I guess this is either different on Windows, or has changed with the latest versions of the SDK. (You can check withnetstat -ban.)

I installed WinSSHD on the machine that runs the emulator. (I believe it should work with freeSSHd as well, but I couldn't get a login working there.)
I opened port 22 (TCP) in the Windows Firewall. (WinSSHD might be able to do that for you.)
I created a virtual account in the WinSSHD GUI.
I created a new PuTTY connection from the development machine to the emulator machine and made sure I could connect.
Then I set up tunnelling in PuTTY: Connection -> SSH -> Tunnels

Source port: 5554
Destination: localhost:5554
Type: Local/Auto

Source port: 5555
Destination: localhost:5555
Type: Local/Auto

(Connect and keep PuTTY open, to maintain the tunnel.)
Now I fired up the emulator on the remote machine and made sure that ADB is not running there.
I restarted ADB on the development machine (adb kill-server, thenadb start-server).
adb devices and the remote emulator showed up as emulator-5554 device. I could now deploy and run my app straight from Eclipse/ADT, where the emulator showed up under Virtual Devices as if it was a local emulator.

方法2

By Patrick McKinnon

I realize this question is really old, but I solved the problem slightly differently, and it took me a while to figure out this trivial solution.

I usually use a Windows7 PC or laptop (depending on where I'm working) as my front-end because I like the GUI, however I prefer to do all of my edit/compile/debug on a headless Ubuntu server because of all the command-line power it provides. My goal is to make each windows system as much of a thin-client as possible without any extra services (such as sshd) or firewall holes.

So here is the senario:

System-A: Windows7 system with android emulator running
System-B: Ubuntu server with SDK installed

The problem as described earlier is that the emulator on System-A binds to localhost, not the external ethernet interface, so adb on the System-B cannot access the emulator on System-A. All you need to do is set up remote port forwarding in PuTTY for your SSH connection to System-B. The trick is to check the "Remote" radio button when you create the two tunnels so that the tunnel direction is reversed (tunneling from the server you are logging into to the client you are logging in from).

Finally, connect with adb to "localhost" on System-B after establishing the SSH connection:

System-B$ adb connect localhost
connected to localhost:5555
System-B$ adb devices
List of devices attached
localhost:5555  device

Now you can download images/debug as normal, and it is a trivial matter to switch to a different Windows system if you want to take your laptop out and get some coffee.

In addition, by also tunneling port 5037 in the same manner you can actually forward your adb server connection so that you can connect a real android device over USB on System-A, and download images to it from System-B. In order for this to work, you need to make sure that the adb server is running on System-A, and not running on System-B before starting your SSH session:

First, start the adb server on System-A (command prompt)

C:\> adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
C:\> adb devices
List of devices attached
3435F6E6035B00EC        device

Next, kill the adb server on System-B

System-B$ adb kill-server

Finally, restart your ssh session to System-B and verify

System-B$ adb devices
List of devices attached
3435F6E6035B00EC        device