Pregunta Depuración remota con emulador de Android


¿Es posible escribir el código / compilar la aplicación de Android en una máquina y depurarlo remotamente en el emulador lanzado en otra? Estoy harto y cansado de que el emulador esté comiendo constantemente la mitad de la CPU de mi computadora portátil.


76
2017-11-18 07:08


origen


Respuestas:


No he intentado previamente (o incluso notado) el adb connect comando que cmb mencionado, pero puedo confirmar que el reenvío de los puertos TCP, como por ejemplo SSH, funciona bien.

El emulador escucha en dos puertos TCP por instancia: 5554 para la interfaz telnet y 5555 para comunicación de control con herramientas como DDMS. Por lo tanto, probablemente podría salirse con la suya solo reenviando el puerto 5555 (aunque solo lo he intentado con ambas cosas). Cada emulador posterior toma la siguiente tupla de número de puerto par + impar (creo que hasta aproximadamente 5580).

Como referencia, hice los siguientes pasos en mi máquina local:

  • ssh -NL 5554:localhost:5554 -L 5555:localhost:5555 myuser@remote-server
  • killall adb; adb devices

Creo que el emulador intenta notificar a un servidor adb local al inicio; de ahí la necesidad de reiniciar adb para que explore los 5554+ puertos locales.

Tenga en cuenta que localhost en el comando ssh se refiere a la interfaz local de la remoto máquina.

adb devices mostró un nuevo emulador emulator-5554 - y podría usarlo como si se ejecutara en mi máquina local.


61
2017-12-19 01:30



Así es como lo resolví en Windows. Casi seguí la iniciativa de Christopher, pero no puedo editar, por lo que una nueva respuesta tendrá que hacer.

El problema que tuve fue que ADB y el emulador solo estaban escuchando en 127.0.0.1, no en 0.0.0.0, para mí. De lo contrario, habría utilizado TCPMon. Supongo que esto es diferente en Windows o ha cambiado con las últimas versiones del SDK. (Puede consultar con netstat -ban.)

  1. lo instalé WinSSHD en la máquina que ejecuta el emulador. (Creo que debería funcionar también con freeSSHd, pero no pude obtener un inicio de sesión trabajando allí).

  2. Abrí el puerto 22 (TCP) en el Firewall de Windows. (WinSSHD podría hacer eso por usted).

  3. Creé una cuenta virtual en la GUI de WinSSHD.

  4. Creé una nueva conexión PuTTY desde la máquina de desarrollo a la máquina emuladora y me aseguré de poder conectarme.

  5. Luego configuré un túnel en PuTTY: Conexión -> SSH -> Túneles

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

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

    (Conecte y mantenga PuTTY abierto, para mantener el túnel).

  6. Ahora encendí el emulador en la máquina remota y me aseguré de que ADB no se ejecuta allí.

  7. Reinicié ADB en la máquina de desarrollo (adb kill-server, entonces adb start-server)

  8. adb devices y el emulador remoto apareció como emulator-5554 device. Ahora podría implementar y ejecutar mi aplicación directamente desde Eclipse / ADT, donde el emulador aparece en Dispositivos virtuales como si fuera un emulador local.


19
2018-05-08 00:15



Me doy cuenta de que esta pregunta es muy antigua, pero resolví el problema de forma ligeramente diferente, y me tomó un tiempo descubrir esta solución trivial.

Usualmente utilizo una PC con Windows7 o portátil (dependiendo de dónde estoy trabajando) como mi interfaz porque me gusta la GUI, sin embargo, prefiero hacer toda mi edición / compilación / depuración en un servidor Ubuntu sin cabeza debido a todo el poder de línea de comandos que proporciona. Mi objetivo es hacer que cada sistema de Windows sea lo más delgado posible sin servicios adicionales (como sshd) o firewalls.

Así que aquí está el senario:

  • Sistema-A: sistema Windows7 con emulador de Android ejecutándose
  • Sistema-B: servidor Ubuntu con SDK instalado

El problema descrito anteriormente es que el emulador del Sistema-A se une al host local, no a la interfaz externa de ethernet, por lo que adb en el Sistema-B no puede acceder al emulador en el Sistema-A. Todo lo que necesita hacer es configurar el reenvío de puertos remotos en PuTTY para su conexión SSH al Sistema-B. El truco es verificar el botón de radio "Remoto" cuando se crean los dos túneles para que la dirección del túnel se invierta (tunelización desde el servidor al que está ingresando al cliente desde el que está iniciando sesión).

tunnel screenshot

Finalmente, conéctese con adb a "localhost" en System-B después de establecer la conexión SSH:

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

Ahora puede descargar imágenes / depuración de forma normal, y es una cuestión trivial cambiar a un sistema Windows diferente si quiere sacar su computadora portátil y tomar un café.

Además, al tunelizar el puerto 5037 de la misma manera, puede reenviar su conexión de servidor adb para que pueda conectar un dispositivo real de Android a través de USB en el Sistema-A y descargarle imágenes desde el Sistema-B. Para que esto funcione, debe asegurarse de que el servidor adb se esté ejecutando en System-A, y no se esté ejecutando en System-B antes de iniciar su sesión SSH:

Primero, inicie el servidor adb en System-A (símbolo del sistema)

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

A continuación, elimine el servidor adb en System-B

System-B$ adb kill-server

Finalmente, reinicie su sesión ssh en System-B y verifique

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

16
2018-04-08 03:48



Encontré una manera fácil de hacerlo si sus dos máquinas están en la misma red privada y, por lo tanto, no es necesario utilizar el cifrado SSH (que es el caso común). Esto puede ayudar ya que un túnel SSH puede ser bastante largo y difícil de instalar. Por ejemplo, instalar un daemon SSH bajo Cygwin / Windows por primera vez puede llevar a renunciar (bueno, me di por vencido).

En Windows, lo que sigue requiere tener instalado Cygwin con el paquete httptunnel. Esto debe funcionar bajo Linux / httptunnel también pero no lo intenté.

  • Ejecute el emulador en una de las máquinas (digamos que su nombre de host es HostEmulator)

  • Inicie Eclipse en la otra máquina (llamémoslo HostEclipse)

  • Abra un terminal Cygwin en cada máquina, y luego,

  • En HostEmulator, ingrese los siguientes comandos de cygwin:

    hts -F localhost:5554 10000
    hts -F localhost:5555 10001
    

hts medio Http Tunnel Server.

Estos dos comandos crean dos medios puentes que escuchan los puertos 10001 y 10001 y que redirigen la E / S de estos puertos a los puertos locales 5554 y 5555, que son los puertos utilizados por el emulador (en realidad, el primer emulador lauched - si están ejecutando varios de ellos, usarán números de puerto más altos como se ve en otras respuestas de esta página).

  • En HostEclipse, ingresa estos:

    htc -F 5554 HostEmulator:10000
    htc -F 5555 HostEmulator:10001
    

htc medio Http Tunnel Client.

Estos comandos crean los medio puentes que faltan. Escuchan los puertos locales 5554 y 5555 y redirigen la E / S de estos puertos a los medios puentes que hemos creado en HostEmulatorjusto antes.

  • Entonces, todavía encendido HostEclipse, ingresa estos tres comandos:

    adb kill-server
    adb start-server
    adb devices
    

Esto reinicia adb ya que de lo contrario no detecta el emulador remoto. Debe estar haciendo un escaneo al inicio. Y luego enumera los dispositivos (los emuladores disponibles) solo para verificar.

  • Y ahí tienes. 

Puede trabajar con su emulador remoto como si fuera local. Tienes que mantener los terminales Cygwin abiertos en ambas máquinas; de lo contrario, eliminarías los medios puentes que creaste.

Usé el puerto 10000 y 10001 para los intercambios máquina / máquina aquí, pero por supuesto puedes usar otros puertos siempre que no estén en uso.


4
2017-08-24 22:04



Un teléfono desarrollador es menos costoso que una computadora adicional y se puede depurar remotamente. Tiene la ventaja adicional de tener todos los sensores opcionales que el emulador no presenta por defecto.

Recomiendo obtener un teléfono de desarrollador para probar.


2
2017-11-21 15:55



Mi solución para Windows + AndroVM (que requiere un adaptador de solo host) cuando mi servicio ssh no se pudo iniciar. por lo que no requiere ningún software adicional.

adb connect <Andro VM IP>
adp tcpip 555

En el prompt de cmd ejecutado como admin:

netsh interface portproxy add v4tov4 listenport=5555 listenaddress=<host ip> connectport=5555 connectaddress=<Andro VM IP>

abra el puerto TCP 5555 en el firewall de Windows.

Luego, desde la segunda ejecución de PC:

adb connect <host ip>

2
2018-06-05 08:50



No tengo una segunda máquina con el SDK a mano, pero observo que los puertos de escucha del emulador (por defecto 5554, 5555) están escuchando 0.0.0.0, es decir, accesible desde máquinas remotas, y eso adb --help Muestra un connect <host>:<port> mando. Supongo que eso lo haría aparecer en adb devices asi que adb los comandos trabajan en eso. Para Eclipse, pruebe "Ejecutar / Ejecutar configuraciones ..." y configure el objetivo en Manual. Eso te da un "selector de dispositivo" que, supongo, incluiría un emulador remoto si adb está conectado a él. Vale la pena intentarlo.


0
2017-11-18 14:38



Ninguna de las soluciones propuestas funcionó para mí. Empecé con la solución de Emirikol y la refiné, ya que con la nueva API de Android> 21 el emulador aparecía sin conexión y tenía que ir a la configuración de Genymotion y dejar la ruta del SDK de Android vacía. Y desde la línea de comando:

netsh interface portproxy add v4tov4 listenport=5555 connectport=5555 connectaddress=<emulatorIP>

netsh interface portproxy add v4tov4 listenport=5554 connectport=5554 connectaddress=<emulatorIP>

fuente:http://www.sarpex.co.uk/index.php/2016/10/02/connect-genymotion-emulator-remotely/ Descargo de responsabilidad, soy el autor.


0
2017-10-02 17:25