movil - log tag android studio

Depuración remota con emulador de Android (9)

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 )

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í).
Abrí el puerto 22 (TCP) en el Firewall de Windows. (WinSSHD podría hacer eso por usted).
Creé una cuenta virtual en la GUI de WinSSHD.
Creé una nueva conexión PuTTY desde la máquina de desarrollo a la máquina emuladora y me aseguré de poder conectarme.
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).
Ahora encendí el emulador en la máquina remota y me aseguré de que ADB no se ejecuta allí.
Reinicié ADB en la máquina de desarrollo ( adb kill-server , luego adb start-server ).
adb devices y el emulador remoto aparecieron 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.

¿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.

Cuando ejecuta adb, inicia una copia del servidor de sí mismo si aún no se está ejecutando. Puede comenzar la copia usted mismo en la máquina con el dispositivo y desde sdk 4.3 puede darle la opción -a para decirle a ese servidor que escuche las máquinas remotas. Hazlo con el siguiente comando que no sale:

adb -a -P 5037 servidor nodaemon

En la máquina desde la que desea utilizar el dispositivo, configure ADB_SERVER_SOCKET en tcp: xxxx: 5037 en una variable de entorno (o proporcione el mismo valor a cada invocación de adb con la opción -L), donde xxxx es la dirección IP o el nombre de host del máquina con los dispositivos, y 5037 coincide con el puerto que dio el en el comando anterior.

Usamos esto para dar acceso a aproximadamente 100 emuladores distribuidos en 3 máquinas a una máquina que ejecuta pruebas de extremo a extremo en paralelo, y a los desarrolladores que desean compartir dispositivos reales de forma remota.

Puede reenviar puertos hacia y desde el emulador con adb forward y adb reverse, y aparecerán en la máquina con los dispositivos.

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 también debe funcionar en Linux / httptunnel , 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 significa 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 , ingrese estos :
htc -F 5554 HostEmulator:10000 htc -F 5555 HostEmulator:10001

htc significa Http Tunnel Client .

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

Luego, aún en HostEclipse , ingrese 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.

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

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

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>

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.

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 en 0.0.0.0 , es decir, accesible desde máquinas remotas, y que adb --help muestra una connect <host>:<port> comando connect <host>:<port> . Supongo que eso lo haría aparecer en los adb devices adb 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.

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.

No he intentado (ni notado) previamente el comando adb connect mencionado por cmb, 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 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 podría usarlo como si se ejecutara en mi máquina local.