Depuração remota com emulador Android

É possível escrever o código / compilar o aplicativo Android em uma máquina e depurá-lo remotamente no emulador lançado em outra? Estou farto de ver o emulador consumir constantemente metade da CPU do meu laptop.

Eu não tentei anteriormente (ou mesmo notei) o adb connectcomando que cmb mencionou, mas posso confirmar que o encaminhamento das portas TCP por conta própria - como por SSH - funciona bem.

O emulador escuta em duas portas TCP por instância: 5554 para a interface telnet e 5555 para controlar a comunicação com ferramentas como DDMS. Portanto, você provavelmente só conseguiria encaminhar a porta 5555 (embora eu só tenha tentado até agora com ambas). Cada emulador subsequente usa a próxima tupla de número de porta par + ímpar disponível (até cerca de 5580, eu acho).

Para referência, executei as seguintes etapas em minha máquina local:

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

Acredito que o emulador tenta notificar um servidor adb local na inicialização; daí a necessidade de reiniciar o adb para que ele analise as portas 5554+ locais.

Observe que localhostno comando ssh se refere à interface local da máquina remota .

adb devicesmostrou um novo emulador - emulator-5554- e eu poderia usá-lo como se estivesse rodando na minha máquina local.

Aqui está como eu resolvi isso no Windows. Eu praticamente segui o exemplo de Christopher, mas não posso editar, então uma nova resposta terá que servir.

O problema que tive foi que o ADB, assim como o emulador, estava apenas ouvindo em 127.0.0.1, e não 0.0.0.0, para mim. Caso contrário, eu teria usado TCPMon . Acho que isso é diferente no Windows ou mudou com as versões mais recentes do SDK. (Você pode verificar com netstat -ban.)

1. Eu instalei WinSSHD na máquina que executa o emulador. (Eu acredito que deveria funcionar com freeSSHd também, mas não consegui fazer um login funcionando lá.)

2. Abri a porta 22 (TCP) no Firewall do Windows. (WinSSHD pode ser capaz de fazer isso por você.)

3. Eu criei uma conta virtual no WinSSHD GUI.

4. Criei uma nova conexão PuTTY da máquina de desenvolvimento para a máquina do emulador e certifiquei-me de que poderia conectar.

5. Então eu configuro o tunelamento no PuTTY: Conexão -> SSH -> Túneis

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

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

   (Conecte e mantenha o PuTTY aberto para manter o túnel.)

6. Agora eu ativei o emulador na máquina remota e certifiquei-me de que o ADB não está sendo executado lá.

7. Eu reiniciei o ADB na máquina de desenvolvimento ( adb kill-serverentãoadb start-server ).

8. adb devicese o emulador remoto apareceu como emulator-5554 device. Eu agora podia implantar e executar meu aplicativo direto do Eclipse / ADT, onde o emulador aparecia em Dispositivos virtuais como se fosse um emulador local.

Sei que essa questão é muito antiga, mas resolvi o problema de maneira um pouco diferente e demorei um pouco para descobrir essa solução trivial.

Eu geralmente uso um PC ou laptop com Windows7 (dependendo de onde estou trabalhando) como front-end porque gosto da GUI, no entanto, prefiro fazer todas as minhas edições / compilação / depuração em um servidor Ubuntu sem cabeça por causa de todos os poder de linha de comando que ele fornece. Meu objetivo é tornar cada sistema Windows o mais thin client possível, sem quaisquer serviços extras (como sshd) ou brechas no firewall.

Então aqui está o senário:

• Sistema-A: sistema Windows7 com emulador de Android em execução
• Sistema-B: servidor Ubuntu com SDK instalado

O problema, conforme descrito anteriormente, é que o emulador no System-A se liga ao host local, não à interface ethernet externa, portanto, o adb no System-B não pode acessar o emulador no System-A. Tudo que você precisa fazer é configurar o encaminhamento de porta remota no PuTTY para sua conexão SSH com o System-B. O truque é marcar o botão de opção "Remoto" ao criar os dois túneis para que a direção do túnel seja invertida (túnel do servidor no qual você está se conectando para o cliente a partir do qual está se conectando).

Por fim, conecte-se com adb a "localhost" no System-B após estabelecer a conexão SSH:

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

Agora você pode baixar imagens / depurar normalmente, e é uma questão trivial mudar para um sistema Windows diferente se quiser pegar seu laptop e tomar um café.

Além disso, também encapsulando a porta 5037 da mesma maneira, você pode realmente encaminhar sua conexão do servidor adb para que possa conectar um dispositivo Android real por USB no System-A e baixar imagens para ele do System-B. Para que isso funcione, você precisa se certificar de que o servidor adb está sendo executado no Sistema-A e não no Sistema-B antes de iniciar sua sessão SSH:

Primeiro, inicie o servidor adb no System-A (prompt de comando)

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

Em seguida, elimine o servidor adb no System-B

System-B$ adb kill-server

Finalmente, reinicie sua sessão SSH para System-B e verifique

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

Descobri uma maneira fácil de fazer isso se suas duas máquinas estiverem na mesma rede privada e, portanto, não precisarem usar criptografia SSH (que é o caso comum). Isso pode ajudar, pois um túnel SSH pode ser muito longo e difícil de instalar. Por exemplo, instalar um daemon SSH no Cygwin / Windows pela primeira vez pode levar à desistência (bem, desisti).

No Windows, o que se segue requer a instalação do Cygwin com o pacote httptunnel . Isso deve funcionar no Linux / httptunnel também, mas eu não tentei.

• Execute o emulador em uma das máquinas (digamos que seu nome de host seja HostEmulator )

• Inicie o Eclipse na outra máquina (vamos chamá-lo de HostEclipse )

• Abra um terminal Cygwin em cada máquina e, em seguida,

• No HostEmulator , digite os seguintes comandos cygwin :

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

hts significa servidor de túnel Http .

Esses dois comandos criam duas meias-ponte que escutam as portas 10001 e 10001 e redirecionam o I / O dessas portas para as portas locais 5554 e 5555, que são as portas usadas pelo emulador (na verdade, o primeiro emulador lançado - se você estiver executando vários deles, eles usarão números de porta maiores, conforme visto em outras respostas desta página).

• Em HostEclipse , insira estes :

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

htc significa cliente de túnel Http .

Esses comandos criam as meias-pontes ausentes. Eles escutam as portas locais 5554 e 5555 e redirecionam a E / S dessas portas para as meias-pontes que criamos no HostEmulator antes.

• Em seguida, ainda no HostEclipse , digite estes três comandos :

  adb kill-server
  adb start-server
  adb devices

Isso reinicia o adb, pois não detecta o emulador remoto de outra forma. Deve estar fazendo alguma varredura na inicialização. E então lista os dispositivos (os emuladores disponíveis) apenas para verificação.

• E aí está.

Você pode trabalhar com seu emulador remoto como se fosse local. Você tem que manter os terminais Cygwin abertos em ambas as máquinas, caso contrário, você mataria as meias-pontes que criou.

Usei as portas 10000 e 10001 para as trocas máquina / máquina aqui, mas é claro que você pode usar outras portas, desde que ainda não estejam em uso.

Minha solução para windows + AndroVM (que requer um adaptador somente host) quando meu serviço ssh falhou ao iniciar. portanto, não requer nenhum software adicional.

adb connect <Andro VM IP>
adp tcpip 555

No prompt cmd, execute como administrador:

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

abra a porta TCP 5555 no firewall do Windows.

Então, a partir do segundo PC, execute:

adb connect <host ip>

Nenhuma das soluções propostas funcionou para mim. Comecei com a solução da Emirikol e a refinei, já que com a nova API Android> 21 o emulador estava aparecendo offline e eu tive que ir para as configurações do Genymotion e deixar o caminho do Android SDK vazio. E na linha de comando:

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

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

fonte: http://www.sarpex.co.uk/index.php/2016/10/02/connect-genymotion-emulator-remotely/ Isenção de responsabilidade, sou o autor.

Quando você executa o adb, ele inicia uma cópia do servidor de si mesmo, se ainda não houver uma em execução. Você pode iniciar essa cópia na máquina com o dispositivo e, desde o sdk 4.3, você pode dar a opção -a para dizer ao servidor para escutar máquinas remotas. Faça isso com o seguinte comando que não sai:

adb -a -P 5037 servidor nodaemon

Na máquina da qual você deseja usar o dispositivo, defina ADB_SERVER_SOCKET como tcp: xxxx: 5037 em uma variável de ambiente (ou dê o mesmo valor para cada chamada de adb com a opção -L), onde xxxx é o endereço IP ou nome de host do máquina com os dispositivos e 5037 corresponde à porta que você forneceu no comando acima.

Usamos isso para dar acesso a cerca de 100 emuladores espalhados por 3 máquinas para uma máquina executando testes de ponta a ponta em paralelo e para desenvolvedores que desejam compartilhar dispositivos reais remotamente.

Você pode encaminhar portas de e para o emulador com adb forward e adb reverse, e elas aparecerão na máquina com os dispositivos (não na máquina em que você está executando o 'adb forward').

Não tenho uma segunda máquina com o SDK disponível, mas observo que as portas de escuta do emulador (padrão 5554, 5555) estão escutando 0.0.0.0, ou seja, acessíveis de máquinas remotas, e isso adb --helpmostra um connect <host>:<port>comando. Suponho que isso o faria aparecer em comandos adb devicespara adbtrabalhar nele. Para Eclipse, experimente "Run / Run Configurations ..." e defina o Target como Manual. Isso dá a você um "seletor de dispositivo" que, imagino, incluiria um emulador remoto se o adb estiver conectado a ele. Vale a pena tentar.