Depuración remota con el emulador de Android

Question

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

Answer 1

No he probado anteriormente (o incluso notado) el comando que adb connect CMB mencionó, pero puedo confirmar que la transmisión de los puertos TCP mismo — como a través de SSH — funciona bien.

El emulador escucha en dos puertos TCP por instancia: 5554 para la interfaz telnet y 5555 para la 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, que hicieron 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 local de ADB en el arranque; de ahí la necesidad de reiniciar adb para que explore los 5554+ puertos locales.

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

adb devices mostraron un nuevo emulador — emulator-5554 — y pude utilizarlo como si se estuviera ejecutando en mi máquina local.

Answer 2

no tengo una segunda máquina con el SDK a mano, pero observo que los puertos escuchar del emulador (por defecto 5554, 5555) están escuchando en 0.0.0.0, es decir, accesible desde máquinas remotas, y que adb --help muestra un comando connect <host>:<port> . Supongo que eso lo haría aparecer en adb devices para que los comandos adb trabajen en él. 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.

Answer 3

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 realizar pruebas.

Answer 4

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 usado TCPMon. Supongo que esto es diferente en Windows o ha cambiado con las últimas versiones del SDK. (Usted puede consultar con netstat -ban.)

1. He instalado WinSSHD en la máquina que ejecuta el emulador. (Creo que debería funcionar también con freeSSHd, pero no pude iniciar 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. Entonces creó un túnel en la masilla: Conexión -> SSH -> Túneles

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

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

   (Conectar y mantener Poner TY abierto, para mantener el túnel.)

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

7. He reiniciado ADB en la máquina de desarrollo (adb kill-server, luego 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.

Answer 5

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

Normalmente utilizo una PC o portátil con Windows 7 (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í es el senario:

• Sistema-R: sistema de Windows 7 con el emulador de Android corriendo
• Sistema-B: servidor de Ubuntu con el SDK instalado

El problema tal como se describe anteriormente es que el emulador en System-A se une a localhost, no a la interfaz externa de ethernet, por lo que adb en el System-B no puede acceder al emulador en System-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).

Por último, conecte con ADB a "localhost" en Sistema-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 

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

Además, al tunelizar también el puerto 5037, puede reenviar la conexión de su servidor adb para que pueda conectar un dispositivo real de Android a través de USB en el Sistema-A y descargarle imágenes del Sistema-B. Para que esto funcione, debe asegurarse de que el servidor adb se ejecuta en el sistema A y no se ejecuta en el sistema 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, terminar el servidor adb en System-B

System-B$ adb kill-server 

por último, reinicie su sesión de ssh para Sistema-B y verificar

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

Answer 6

He encontrado 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).

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

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

• inicio de Eclipse en la otra máquina (vamos a llamarlo HostEclipse)

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

• En HostEmulator, introduzca los siguientes comandos cygwin:

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

HTS significa HTTP túnel servidor.

Estos dos comandos crean dos medio puente 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, 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, introduzca estos:

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

HTC significa Http túnel de cliente.

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

• Entonces, todavía en HostEclipse, introduzca estos tres comandos:

  adb kill-server 
  adb start-server 
  adb devices 
  

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

• Y listo.

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

He utilizado el puerto 10000 y 10001 para los intercambios máquina/máquina aquí, pero por supuesto se pueden utilizar otros puertos, siempre y cuando no están en uso.

Answer 7

Mi solución para las ventanas + AndroVM (que requiere un adaptador de host-only) 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 ejecución de cmd como administrador:

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.

continuación, en la segunda pasada PC:

adb connect <host ip> 

Answer 8

Ninguna de las soluciones propuestas trabajó para mí. Empecé con la solución de Emirikol y la perfeccioné, 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 vacía la ruta del SDK de Android. Y desde la línea de comandos:

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/ exención de responsabilidad, soy el autor.