Is there a way to fake calls for android devices that I have plugged in via usb? Some way to trigger a call using ADB? If so, how do I do it?
I feel like this might be a duplicate question but I can't find a SO question for it. This is the closest question, but it only relates to the emulator.
Here's some things I've tried. I would like to do the reverse of the following command:
adb shell am start -a android.intent.action.CALL tel:1112223333
Just like the other guy said in the question I linked to above. Except I would like to do this on a device, instead of in the emulator. For the work that I am doing the emulator is not sufficient for testing phone calls, I can only run my tests on actual devices. Our "solution" doesn't have emulator support.
So normally I would telnet into the local host using the emulator's port but I can't do that, so can I telnet into a plugged in device? Is there a way for me to fake an incoming call on a plugged in device?
To explain why I would want to do this, I am making modifications to AOSP at this time. At the moment we have not modified the emulator to work with our changes, but we are making modifications to telephony. Eventually getting the emulator to work will be important but at this time it would be ideal if we could test telephony with fake calls using the devices we have access to.
It is entirely possible that this is not even possible but if someone has experience with this I would love to know. I feel like there should be some tests somewhere for faking phone calls on devices before they release a device to the public.
Telnet to your Android device
Alternatively to adb you can also use telnet to connect to the device. This allows you to simulate certain things, e.g. incoming call, change the network connectivity, set your current geocodes, etc. Use "telnet localhost 5554" to connect to your simulated device. To exit the console session, use the quit or exit command.
For example
# connects to device
telnet localhost 5554
# set the power level
power status full
power status charging
# make a call to the device
gsm call 012041293123
# send a sms to the device
sms send 12345 Will be home soon
# set the geo location
geo fix 48 51
Related
We are working on a device which is running on android ICS 4.0.4 and 3.0.35 kernel. The issue we are facing is with device power management and network reach-ability. once device comes up from suspend mode it is not able to ping any ip address say 8.8.8.8 immediately. some times it take a minute or 2 minutes or sometime it becomes unreachable telling buffer space not available/ destination unreachable. but if we ping this device ip from outside it is responding and from device side also it starts getting ping reply from 8.8.8.8 what could be the reason for such behavior? and where could be the problem? we are clueless, the connection is through mobile data i.e. pppd. every thing seems OK in android UI it shows connected and maintains ip also, but not able to ping anybody after resuming from suspend. because of this issue device cannot browse immediately. where could be the problem, in Android? or kernel Power management? or PPP? If anybody have faced such issue and found any solution please help.
The use case is allow android device to go into suspend mode, wait until it goes to deep sleep. wake it manually and ping any ip say 8.8.8.8 from device's android terminal.
Expected
Immediate reply for ping request.
Check whether ttyUSB or ttyACM ports are working proper after suspend/resume
The issue was with modem firmware. ttyUSB* points were use to hang, once the host M/C goes to suspend. After device resume it was not responding to any AT commands. So to prove the modem, we have experimented on ubuntu laptop.
Modem was connected to the ubuntu Laptop then allowed Laptop to go to sleep mode, after that when we resumed the laptop and issued AT commands at ttyUSB* there was no response from the modem.
So the point was clear that issue was with the modem not with our Android device. subsequently modem vendor corrected the issue in new firmware after that device retained its reachability even after host device goes to sleep and wakeup modes.
I'm trying to make call for testing purposes in my bluestacks android emulator.
I tired
telnet localhost 5555
but my cmd goes blank after this.
Command prompt after telnet command
Why is it showing blank?
Is there any other way to call to an android emulator.
Edit:
I need to process incoming call in my android application, so I need to generate a fake call.
The application I'm trying to build also require root(Super User) access.
I tried using Android Studio AVD, it can make incoming calls using telnet or ddms but what I want to do requires root permission.
I tried genymotion but the free version doesn't allow calling feature.
So I'm stuck with Bluestacks, it rooted by default & I just need way to generate an actual incoming call just like
gsm call 123456789
So, let me start off by saying that I am 'relatively' familiar and comfortable with making Android apps and using both LogCat and DDMS to debug.
That being said, I'm encountering more of a logistical issue than anything else right now - I am making a locative app, where the GPS is fuelling and controlling other methods in my Activity, and after a while, it is crashing.
Now, because it is locative, I am walking around to test it, in order to receive different GPS locations. Because of this, I am not connected to my computer at the time that it crashes, so have no way (that I know of) to read the stack trace, etc.
In my particular instance, I am navigating through a series of activities, and finally reach the penultimate screen in my app, and while I am running the application in my studio, it runs indefinitely without issue. It is only when I take the device outside that it crashes...
I am wondering if anyone has any tips or tricks with this issue - I'm sure give the prevalence of locative apps, it must have come up, but I cant seem to find the right search terms. It could be as simple as saving the LogCat to file, and/or the stackTrace, but I'm not sure that's the answer...
Thanks in advance.
If I got you right, this is what you are looking for:
https://play.google.com/store/apps/details?id=org.jtb.alogcat&hl=de
Edit: Also there are many more apps like this. You can just browse around in Google Play Store
You can debug the app without rooting your android, unlike the other responses. start off by plugging the android into your computer, then run adb devices to make sure the device is there. Then, run tcpip 5555 to change the android to tcp mode, which will allow debugging over wifi. Disconnect the android from the computer, and connect to it by typing adb 192.168.x.xxx, replacing the x's with your android's IP address. It should connect with no issues, as long as port 5555 is open, and both the android and your computer is on the same wifi.
Simple: Wireless ADB
One of the reason that I choose to run CyanogenMod on my testing devices is that it is a stripped down version of Android that has some additional developer tools, one of those being the ability to access the wireless portion of the ADB system.
As you are probably unaware, you are able to establish an ADB connection to your device over WiFi, however, if running a stock ROM, this requires root access, as it can be potentially harmful to your device, as Wireless ADB will work even over your cellular network, meaning that you could potentially receive apps from other insert carrier here's devices.
If you wish to run WirelessADB, here is a Play Store app that will help you to enable the feature on your device. Requires ROOT
It is as simple as connecting your device to your local WiFi network, (same one the development computer is connected to), enable Wireless ADB, and then running the following command on your computer:
adb connect 192.168.1.101
Replacing 192.168.1.101 with the IP address of your android device.
By establishing this connection, you can run everything just as you would if the device was plugged in via USB Cable.
I recommend ACRA (Application Crash Reports for Android ). It allows you to send crash reports to a number of different destinations. See https://github.com/ACRA/acra/wiki/BasicSetup
I would like to get packet level data traffic captures (.pcap) in Android during a week (in several files if possible).
I thought that I could use tcpdump via Shark, however I find that the capture stops after some time. The biggest packet capture I got is around 40MB. I found out that tcpdump stops/crashes when changing the network interface. For example, when the phone is connected to 3G, when I run tcpdump from Shark I can see the process of tcpdump running until I switch on WiFi.
In the Galaxy S2, when connected via WiFi I have the following interfaces (got by using netcfg in adb shell): lo, svnet0, usb0, sit0, eth0. When I connect via 3G, I get pdp0 instead of eth0.
Is there any way that I can run tcpdump 24/7? Or any way to check when it is running and if it stops make it run again from a Java app? Checking the process of tcpdump or something like this maybe? Or monitoring the status of the network and running tcpdump every time the network is changed?
I had a look to: ReadLine on TCPDump-Buffer sometimes blocks until kill tcpdump , but it does not completely solve my problem.
I am using rooted devices.
How about trying tPacketCapture application ( works with non-rooted devices)
Android OS 4.0
Free
https://play.google.com/store/apps/details?id=jp.co.taosoftware.android.packetcapture
If you have rooted device then use SimplePacketCapture instead of tPacketCapture.
tPacketCapture creates a vpn that can break your voip application.
I'v tried as follow to see what's going on about tcpdump after alternating network interface.
1.open wifi run tcpdump-arm
2.run ps|grep tcpdump-arm
3.close wifi and open mobile interface
4.run ps|grep tcpdump-arm
I've found that when alternating the network interface on the mobile phone, the tcpdump-arm process is still working, but it captures no packets.
I think you need tcpdump to keep capturing even when the network interface changed.
You can catch the connectivity change broadcast as the tutorial of google says at first.
Then, you should run "killall" to kill the tcpdump processl
At last, restart the tcpdump process, if you don not specify an interface, it will listen on the newly opened interface.If you would like the tcpdump to return quickly, you can add "-l" option as the answer in TCPDump-Buffer sometimes blocks until kill tcpdump implies.
I need this in order to debug CDMA data (SMS recieved and sent)
This can be done by sending commands to your Android emulator via Telnet.
To begin make sure your android emulator is running, then in a console:
telnet localhost 5554.
This will connect you to the emulator (note that the port 5554 may change depending on your setup. This port will be in the title of the emulator.)
Now enter gsm voice off. You can also tweak different network parameters; just type help for available commands.