I am trying to connect to an Android device connected to my laptop while developing and writing code via Remote Desktop and VPN on my work machine.
What I would like to do is to build on the remote machine and deploy to android phone via VPN connection to android device connected on the laptop via USB.
I tried following another post but was unable to get it to work.
Here is what I did so far.
Forked ADB server on laptop:
adb -a -P 5037 fork-server server&
Connected to my server from desktop:
adb connect mylaptopname:5038
UPDATE
I also tried following instructions from this post I also do not see my devices.
I run this on the laptop adb -a -P <PORT_NUMBER> nodaemon server and then run this on the desktop where I develop adb -H <REMOTE_IP> -P <PORT_NUMBER> devices I still do not see the device.
I get this back: List of devices attached and nothing else, indicating it does not see any devices.
The connection was successful but my desktop still does not see the phone.
I would like to run automatized test on different Genymotion devices in the same time. For this I have to give seperate port numbers for each device.
Is it possible?
From the Genymotion Launcher, you are able to start multiple VMs. Although these each will have the same default port (5555), they will get different IP addresses from the VirtualBox host-only adapter. For example, I just launched two Genymotion machines and now adb devices shows:
$ adb devices
List of devices attached
192.168.56.101:5555 device
192.168.56.102:5555 device
$
Each can be addressed separately by specifying IP address and port in your TCP/IP socket program, or by using adb -s if you're doing manual command line work or writing scripts. I won't go into socket programming here, but here's a quick example of selective access using adb to see if the Location service is running on the second device:
$ adb -s 192.168.56.102:5555 shell service check location
Service location: found
$
I have a modified android device with both a adb port and a serial port. I can connect just fine to my imac (runing OSX 10.6.8) using the adb port. However, when trying to connect to the serial port (and run minicom) my mac computer does not see the device, while a linux computer does.
I have tried:
on a terminal on the mac:
ls /dev/tty.* (all I see are bluetooth connections)
ls /dev/cu.* (same as above)
sudo dmesg | grep -e tty (I see no response)
sudo dmesg | grep -e usb (same as above)
I've looked in System Profiler and do not see my device is connected
Others have had issues not being able to connect via adb because of an EasyTeather app running. I've check and don't have this software installed.
I have put the device into debug mode via the adb port and tried to see the serial port to no avail.
I literally can unplug from the mac and, not changing anything else plug into the linux machine and see it immediately.
I have power cycled both computer and device...many times.
The android OMAPpedia site gives instructions for minicom (http://omappedia.org/wiki/Android_Build_Minicom) and does not mention connecting with apple computers, so perhaps it's just not doable?
Thanks
we have android + linux m/c, we log in into linux shell and boot the machine in android GUI.
now we have the some script that is running on the same machine through linux shell. In that case when the script hangs we need to restart android machine. but it result into restarting the linux machine too. as they are on same machine. so i need the way to restart the android so it comes out of hang state and control remains on the script that is running through the linux shell.
so is there any adb or linux command that work for me?
Have you tried simply 'reboot' with adb?
adb reboot
Also you can run complete shell scripts (e.g. to reboot your emulator) via adb:
adb shell <command>
The official docs can be found here.
You can reboot the device by sending the following broadcast:
$ adb shell am broadcast -a android.intent.action.BOOT_COMPLETED
adb reboot should not reboot your linux box.
But in any case, you can redirect the command to a specific adb device using adb -s <device_id> command , where
Device ID can be obtained from the command adb devices
command in this case is reboot
I think the only way to do this is to run another machine in parallel and use that machine to issue commands to your android box similar to how you would with a phone. If you have issues with the IP changing you can reserve an ip on your router and have the machine grab that one instead of asking the routers DHCP for one. This way you can ping the machine and figure out if it's done rebooting to continue the script.
My scenario is this: I telework from home and log into my work machine via Windows Remote Desktop. I use Eclipse as my development environment for Android apps on my work computer.
Using ADB, I would like to be able to deploy apps from my work computer to a device on my home network, for scenarios where the emulator doesn't do the app justice.
I found this post, which discuss a very similar scenario, with the exception of deploying to an emulator running on a local PC, instead of deploying to a local device:
http://www.41post.com/5003/programming/android-adb-remote-emulator-access
I'm trying to take the same steps, but figure out how to target a local device on my home WiFi network & tethered to my local home PC, instead of the local emulator.
Right now, I have the remote PC set up to try and connect to my public router IP on port 5585 - but in my router, what IP/port do I forward this to to connect to the local device?
In the example using the emulator, they forward to the local PC address where the emulator is running and port 5555, and adb is not running on the local PC. I have configured my router to forward to my device IP, with the device on WiFi, as well as my local PC IP where the device is tethered.
However in both scenarios, when I try adb connect <routerIP>:5585 on my remote PC, it gives me an error unable to connect to <routerIP>:5585:5585. I get the same response when trying to forward to/listen to other ports. I'm not getting any security errors in the router log, so it appears the port forwarding is working.
Questions:
What local IP/port number should I forward to when configuring port forwarding on my local network to connect to the local device using the remote adb instance?
Should I be targeting the local PC IP that the device is tethered to, or the local device IP?
If I target the local device IP, what port number should I forward to?
Do I need adb running on my local PC?
I had a similar situation. I work on a remote desktop for development but my android device is connected to my local laptop. I wanted to be able to use adb and the android plugin in eclipse on the remote desktop and connect to the device attached to my laptop. After searching on the internet and not finding anything that really helped, I decided to write a port forwarder that would do the trick. You can find it here. I hope it will be helpful to other people as well.
Beginning Android 4.3 you can:
Make adb server listen on all interfaces. You have two options:
Make gListen=1 and recompile adb (I have compiled it on Linux-x64 machine for you and put it here)
Start adb server with -a parameter: adb -a -P 5037 fork-server server&
Use adb on your remote machine with extra parameter, e.g. adb -H <remote_host> shell
Another setup for remote host + local device testing. This will be useful for lots of people working from home on a laptop, connected to their development host machine still in the office. Note that I assume both devhost/laptop are both running Unix, but other OSes will be able to run the commands on the command prompt/shell.
# Kill old adb server.
devhost$ adb kill-server
# Activate adb server on client
laptop$ adb start-server
# Start ssh tunnel. Hide/minimize this window not to close it by accident
laptop$ ssh -XC -R 5037:localhost:5037 <your devhost machine>
# Should work by now with the local device connected to the laptop
devhost$ adb logcat
You can solve the issue by port forwarding.
Download Secure Shell app from the Chrome app store
Connect to your machine (step-by-step setup)
In this connection, disable adb server: adb kill-server
Create a new port forwarding connection (same as a regular connection, but set the SSH Arguments field to: -N -R 5037:localhost:5037)
On your laptop, open up a terminal and enable adb server: adb start-server
Probably there is a simpler solution, providing the device, the local and remote machine belong to the same network.
Let's say your device has a certain IP over the network and let's say you decide to use your preferred PORT: well, you can do the following steps.
On the machine where the device is plugged please run:
adb devices
adb tcpip <PORT>
Example of PORT is 5555.
On the remote machine you need to deactivate 'Discover USB devices', 'Discover network targets' and 'Port forwarding' and then run:
adb connect IP:PORT
*IP is your android device IP(not the first machine IP) which can get from adb shell ip -f inet addr
And you are ready to debug on remote machine.
This is how I made it work from host macOS with emulator to macOS client.
A: One line command
On host of emulator
socat tcp-l:5560 tcp:localhost:5559
On client
adb connect <IP>:5560
B: With a tunnel
on host
host$ adb kill-server
host$ adb -a nodaemon server
on client
client$ adb kill-server
client$ ssh -L 5037:localhost:5037 <host-IP>
open second shell on client
client$ adb kill-server # I observe first it kills client adb
client$ adb kill-server # then it kills server adb, do it maybe once more
client$ adb devices # show devices on server now
Now I see host emulator in Android Studio as well
My situation required using a VM that is on a different network, but that I rmd into (an Azure VM). The VM and my local laptop are both running Windows 10. First, I had to install USB Redirector RDP Edition on my local machine (costs $80, but there might be free alternatives), then install the Google Android USB driver on the VM and the Universal Adb Driver on the VM. I'm now able to load an Android Studio App the project in Android Studio on the VM, connect an Android device on my laptop, and debug the app on the device.