Débogage à distance avec Android
Est-il possible d'écrire le code/compiler Android sur une machine et de la déboguer à distance sur l'émulateur lancé sur une autre? J'en ai marre que l'émulateur mange constamment la moitié du CPU de mon ordinateur portable .
Je n'ai jamais essayé (ni même remarqué) le adb connect commande mentionnée par cmb, mais je peux confirmer que le transfert des ports TCP vous-même - par exemple via SSH) fonctionne correctement.
L'émulateur écoute deux TCP par instance: 5554 pour l'interface telnet et 5555 pour contrôler la communication avec des outils comme DDMS. Vous pourriez donc probablement vous en tirer avec le seul port de transfert 5555 (bien que j'aie seulement essayé jusqu'à présent avec les deux.) Chaque émulateur suivant prend le prochain tuple de numéro de port pair + impair disponible (jusqu'à environ 5580, je pense).
Pour référence, j'ai effectué les étapes suivantes sur ma machine locale:
ssh -NL 5554:localhost:5554 -L 5555:localhost:5555 myuser@remote-serverkillall adb; adb devices
Je crois que l'émulateur essaie de notifier un serveur adb local au démarrage; d'où la nécessité de redémarrer adb pour qu'il puisse sonder les ports 5554+ locaux.
Notez que localhost dans la commande ssh fait référence à l'interface locale de la machine distante.
adb devices a montré un nouvel émulateur - emulator-5554 - et je pourrais l'utiliser comme s'il fonctionnait sur ma machine locale.
Voici comment je l'ai résolu sur Windows. J'ai à peu près suivi l'exemple de Christopher, mais je ne peux pas modifier, donc une nouvelle réponse devra faire.
Le problème que j'ai eu, c'est que ADB ainsi que l'émulateur écoutaient juste sur 127.0.0.1, pas sur 0.0.0.0, pour moi. Sinon, j'aurais utilisé TCPMon . Je suppose que cela est différent sous Windows ou a changé avec les dernières versions du SDK. (Vous pouvez vérifier avec netstat -ban.)
J'ai installé WinSSHD sur la machine qui exécute l'émulateur. (Je pense que cela devrait également fonctionner avec freeSSHd, mais je n'ai pas pu obtenir de connexion.)
J'ai ouvert le port 22 (TCP) dans le pare-feu Windows. (WinSSHD pourrait être en mesure de le faire pour vous.)
J'ai créé un compte virtuel dans l'interface graphique WinSSHD.
J'ai créé une nouvelle connexion PuTTY de la machine de développement à la machine d'émulation et je me suis assuré que je pouvais me connecter.
Ensuite, j'ai configuré le tunneling dans PuTTY: Connexion -> SSH -> Tunnels
Source port: 5554Destination: localhost:5554Type: Local/AutoSource port: 5555Destination: localhost:5555Type: Local/Auto(Connectez et gardez PuTTY ouvert pour maintenir le tunnel.)
Maintenant, j'ai lancé l'émulateur sur la machine distante et je me suis assuré que ADB ne fonctionne pas là-bas.
J'ai redémarré ADB sur la machine de développement (
adb kill-server, puisadb start-server).adb deviceset l'émulateur distant est apparu commeemulator-5554 device. Je pouvais maintenant déployer et exécuter mon application directement depuis Eclipse/ADT, où l'émulateur s'est affiché sous Virtual Devices comme s'il s'agissait d'un émulateur local.
Je me rends compte que cette question est vraiment ancienne, mais j'ai résolu le problème légèrement différemment, et il m'a fallu un certain temps pour trouver cette solution triviale.
J'utilise habituellement un PC ou un ordinateur portable Windows7 (selon l'endroit où je travaille) comme interface car j'aime l'interface graphique, mais je préfère faire toutes mes modifications/compilation/débogage sur un serveur Ubuntu sans tête à cause de tous les puissance de ligne de commande qu'il fournit. Mon objectif est de faire de chaque système Windows autant d'un client léger que possible sans aucun service supplémentaire (comme sshd) ou trous de pare-feu.
Voici donc le senario:
- System-A: système Windows7 avec Android en cours d'exécution
- System-B: serveur Ubuntu avec SDK installé
Le problème décrit ci-dessus est que l'émulateur sur System-A se lie à localhost, pas à l'interface Ethernet externe, donc adb sur System-B ne peut pas accéder à l'émulateur sur System-A. Tout ce que vous devez faire est de configurer la redirection de port à distance dans PuTTY pour votre connexion SSH à System-B. L'astuce consiste à cocher la case d'option "À distance" lorsque vous créez les deux tunnels afin que la direction du tunnel soit inversée (tunneling du serveur auquel vous vous connectez au client à partir duquel vous vous connectez).
Enfin, connectez-vous avec adb à "localhost" sur System-B après avoir établi la connexion SSH:
System-B$ adb connect localhost
connected to localhost:5555
System-B$ adb devices
List of devices attached
localhost:5555 device
Maintenant, vous pouvez télécharger des images/déboguer comme d'habitude, et il est trivial de passer à un autre système Windows si vous voulez sortir votre ordinateur portable et prendre un café.
De plus, en tunnelant le port 5037 de la même manière, vous pouvez réellement transférer votre connexion au serveur adb afin de pouvoir connecter un véritable Android périphérique via USB sur System-A, et télécharger des images sur celui-ci à partir de System-B. Pour que cela fonctionne, vous devez vous assurer que le serveur adb s'exécute sur System-A et ne s'exécute pas sur System-B avant de démarrer votre session SSH:
Tout d'abord, démarrez le serveur adb sur System-A (invite de commande)
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
Ensuite, tuez le serveur adb sur System-B
System-B$ adb kill-server
Enfin, redémarrez votre session ssh sur System-B et vérifiez
System-B$ adb devices
List of devices attached
3435F6E6035B00EC device
J'ai trouvé un moyen facile de le faire si vos deux machines sont dans le même réseau privé et n'ont donc pas besoin d'utiliser le cryptage SSH (ce qui est le cas commun). Cela peut être utile car un tunnel SSH peut être assez long et difficile à installer. Par exemple, l'installation d'un démon SSH sous Cygwin/Windows pour la première fois peut conduire à abandonner (enfin, j'ai abandonné).
Sous Windows, ce qui suit nécessite que Cygwin soit installé avec le package httptunnel . Cela doit également fonctionner sous Linux/ httptunnel mais je n'ai pas essayé.
Exécutez l'émulateur sur l'une des machines (disons que son nom d'hôte est HostEmulator )
Démarrez Eclipse sur l'autre machine (appelons-le HostEclipse )
Ouvrez un terminal Cygwin sur chaque machine, puis,
On HostEmulator , entrez les commandes cygwin suivantes:
hts -F localhost:5554 10000 hts -F localhost:5555 10001
hts signifie Serveur de tunnel Http .
Ces deux commandes créent deux demi-ponts qui écoutent les ports 10001 et 10001 et qui redirigent les E/S de ces ports vers les ports locaux 5554 et 5555, qui sont les ports utilisés par l'émulateur (en fait, le premier émulateur lancé - si vous êtes plusieurs d'entre eux en cours d'exécution, ils utiliseront des numéros de port plus élevés comme on le voit dans les autres réponses de cette page).
On HostEclipse , entrez ceux-ci:
htc -F 5554 HostEmulator:10000 htc -F 5555 HostEmulator:10001
htc signifie Client de tunnel Http .
Ces commandes créent les demi-ponts manquants. Ils écoutent les ports locaux 5554 et 5555 et redirigent les E/S de ces ports vers les demi-ponts que nous avons créés sur HostEmulator juste avant.
Ensuite, toujours sur HostEclipse , entrez ces trois commandes:
adb kill-server adb start-server adb devices
Cela redémarre adb car il ne détecte pas l'émulateur distant autrement. Il doit faire une analyse au démarrage. Et puis il répertorie les périphériques (les émulateurs disponibles) juste pour vérification.
- Et c'est parti.
Vous pouvez travailler avec votre émulateur distant comme s'il était local. Vous devez garder les terminaux Cygwin ouverts sur les deux machines, sinon vous tueriez les demi-ponts que vous avez créés.
J'ai utilisé les ports 10000 et 10001 pour les échanges machine/machine ici, mais bien sûr, vous pouvez utiliser d'autres ports tant qu'ils ne sont pas déjà utilisés.
Ma solution pour Windows + AndroVM (qui nécessite un adaptateur hôte uniquement) lorsque mon service ssh n'a pas pu démarrer. il ne nécessite donc aucun logiciel supplémentaire.
adb connect <Andro VM IP>
adp tcpip 555
Sur l'invite cmd, exécutez en tant qu'administrateur:
netsh interface portproxy add v4tov4 listenport=5555 listenaddress=<Host ip> connectport=5555 connectaddress=<Andro VM IP>
ouvrez TCP port 5555 dans le pare-feu Windows.
Ensuite, à partir de la deuxième exécution du PC:
adb connect <Host ip>
Un téléphone développeur est moins cher qu'un ordinateur supplémentaire et peut être débogué à distance. Il a l'avantage supplémentaire d'avoir tous les capteurs optionnels que l'émulateur ne présente pas par défaut.
Je recommande fortement d'obtenir un téléphone de développeur pour les tests.
Aucune des solutions proposées n'a fonctionné pour moi. Je suis parti de la solution d'Emirikol et je l'ai affinée, comme avec le nouveau Android API> 21, l'émulateur apparaissait hors ligne et j'ai dû aller dans les paramètres de Genymotion et laisser Android Chemin SDK vide. Et à partir de la ligne de commande:
netsh interface portproxy add v4tov4 listenport=5555 connectport=5555 connectaddress=<emulatorIP>
netsh interface portproxy add v4tov4 listenport=5554 connectport=5554 connectaddress=<emulatorIP>
source: http://www.sarpex.co.uk/index.php/2016/10/02/connect-genymotion-emulator-remotely/ Avertissement, je suis l'auteur.
Lorsque vous exécutez adb, il démarre une copie de lui-même du serveur si celle-ci n'est pas déjà en cours d'exécution. Vous pouvez démarrer cette copie vous-même sur la machine avec l'appareil et depuis sdk 4.3, vous pouvez lui donner l'option -a pour dire à ce serveur d'écouter les machines distantes. Faites cela avec la commande suivante qui ne se ferme pas:
adb -a -P 5037 serveur nodaemon
Sur la machine à partir de laquelle vous souhaitez utiliser le périphérique, définissez ADB_SERVER_SOCKET sur tcp: xxxx: 5037 dans une variable d'environnement (ou donnez la même valeur à chaque appel adb avec l'option -L), où xxxx est l'adresse IP ou le nom d'hôte du machine avec les périphériques, et 5037 correspond au port que vous avez donné dans la commande ci-dessus.
Nous l'utilisons pour donner accès à une centaine d'émulateurs répartis sur 3 machines à une machine exécutant des tests de bout en bout en parallèle, et aux développeurs souhaitant partager à distance des appareils réels.
Vous pouvez transférer des ports vers et depuis l'émulateur avec adb forward et adb reverse, et ils apparaîtront sur la machine avec les périphériques (pas la machine sur laquelle vous exécutez 'adb forward').
Je n'ai pas de deuxième machine avec le SDK sous la main, mais je note que les ports d'écoute de l'émulateur (par défaut 5554, 5555) écoutent sur 0.0.0.0, c'est-à-dire accessible à partir de machines distantes, et que adb --help montre un connect <Host>:<port> commande. Je suppose que cela apparaîtrait dans adb devices so adb Les commandes fonctionnent dessus. Pour Eclipse, essayez "Run/Run Configurations ..." et définissez la cible sur Manual. Cela vous donne un "sélecteur de périphérique" qui, je suppose, comprendrait un émulateur distant si adb y est connecté. Ça vaut le coup d'essayer.