I have root my Android mobile (Spice MI 270). I want to run AT commands. But whenever I try to run any AT command form shell, it is giving messages as 'AT not found'. My whole purpose of routing is to give AT commands to modem.
How should I proceed?
Thanks.
You can use the program atinout which will allow you to easily send AT commands from the commands line. Example to hang up a call:
$ echo ATH | atinout - /dev/ttyACM0 -
ATH
OK
$
You need to find the name of the serial device for android (on desktop linux it is typically /dev/ttyACM0 but Android use something different as far as I remember).
Related
I have a rooted Xperia Neo V (running quite old Android - 2.3.4). Im trying to run AT commands on /dev/smd0. Most of the things work fine except I'm able to send DTMF tone only once, after that VTS command does not have any effect, even the simple AT command or other commands cease to work i.e. do not give any response after that unless I reboot the phone.
Sequence of events:
1. Test AT command is working:
echo -e "AT\r" > /dev/smd0;cat /dev/smd0
AT
OK
Make/receive a call either through UI or ATD/ATA.
Test AT Command is working:
echo -e "AT\r" > /dev/smd0;cat /dev/smd0
AT
OK
Send DTMF: (I can hear the tone on the other end)
echo -e "AT_VTS=3\r" > /dev/smd0;cat /dev/smd0
At this point all commands (AT+VTS=4, AT, ATI, etc etc) stop working till I reboot the phone. Im not able to hear any further DTMF tones with VTS command.
Observations:
1. I even tried doing a terminal Mitm using mulliner's code (http://mulliner.org/security/sms/feed/android_injector_v1.tgz) to understand how Android is sending DTMF tones correctly. However, the mitm does not work (no output in injector.log). Please note that it works when I send AT commands manually through the shell i.e. logs everything perfectly.
Even if /dev/smd0 is renamed, the ril/Android works fine. My assumption is that it is using some other Qualcomm dev file in case /dev/smd0 fails.
Info:
1. Phone: Sony Ericson Xperia Neo V
[ro.build.description]: [MT11i-user 2.3.4 4.0.2.A.0.62
2. dev file:
$ adb shell getprop | grep -i rild.libargs
[rild.libargs]: [-d /dev/smd0]
Baseband:
echo -e "ATI\r" > /dev/smd0;cat /dev/smd0
ATI
Manufacturer: QUALCOMM INCORPORATED
Model: 196
Revision: M7630A-ABBQMAZM-2.0.3028DT 1 [Sep 14 2011 11:00:00]
IMEI: XXXXXXXXXXXXXXXXXX
+GCAP: +CGSM,+FCLASS,+DS
Since your Sony Ericsson phone is based on Qualcomm's and not ST-Ericsson's platform I do not know any specific implementation details, but since I implemented the AT+VTS command for ST-Ericsson in 2008, I'll give it a shot.
First of, your command example is saying AT_VTS while the command is AT+VTS. I assume that is just a typo while writing this question?
Regarding deleting /dev/smd0 I think this is just rather that the RIL daemon is holding the file open, and thus deleting it in the file system has no effect on processes that have the file opened (until they close it) in the normal unix filesystem behaviour.
I do not know how opening + closing and reopening the device file repeatedly (which is done when running multiple command in sequence like that) will affect things on this phone, but in best case it does not matter and in worst case there might be some trouble related, so I suggest that you use my atinout for sending AT commands and receiving responses. With that you would instead of the echo + cat commands run
echo "AT" | atinout - /dev/smd0 -
echo "AT+VTS=3" | atinout - /dev/smd0 -
echo "ATI" | atinout - /dev/smd0 -
which will open the device once, write the command line once, and read the response(s) back before closing the device when exiting. And it is nicer to use since you do not have to mess with carriage return.
Running three commands like above will open and close the device three times. It would be very interesting to try to run all of them in one operation, e.g
echo "AT; +VTS=3; I" | atinout - /dev/smd0 -
and/or
cat > commands.txt <EOF
AT
AT+VTS=3
ATI
EOF
atinout commands.txt /dev/smd0 -
to see if any of those makes any difference. Will ATI print anything?
Unfortunately I have no experience in compiling atinout on android, so I have no help to offer there.
I need to run ping request on my Android phone using the following format:
ping google.com | while read pong; do echo " $pong #$(date)"; done
There are some applications, such as Terminal Emulator which do that. But just in case I'm curious if I can run shell commands on phone using my PC connection, when the phone is connected to my PC?
EDIT: Yes, it works with the command. But for > r.log it needs root. Any suggestions for that?
Enable developer mode on the phone and use adb tool from Android SDK to do that.
I am not sure how powerful adb's shell is, but give it a try.
You can do even more with adb, check its help.
I have a task at work to investigate if it is possible to send AT commands to an android device via ADB shell. So far,I have tried to echo out the AT commands but it passes them as normal strings.
Any help please anyone.
Please try this:
echo -e "AT+CFUN=?\r\n" > /dev/ttyUSB0
On your phone, the serial line must not necessarily be called ttyUSB0. If this is not working or not available, check out the other entries of the /dev/ directory.
So it could also be /dev/ttyGS0 or /dev/SMD0 (as found out by #Sani).
For further information, please check out this Guide
NOTE:
There might also be phones, that do not respond to AT commands on any of their serial (tty) devices.
I just tried my own procedure on a Samsung Galaxy S4 and did not have any success.
Echo them where? In Android you talk to the rild (Radio Interface Layer) daemon, which in turns talks to a proprietary library, which sends commands to the actual hardware. Check rild source code for details. You could probably write a command line program that talks to the rild and execute it via adb shell, if that fits your needs.
In order to find out which port to use :
You can check
# cat /proc/tty/drivers
Use logcat -b radio | grep dev to see wich tty the radio is using.
Yes you can run AT commands from adb shell too...
prerequsite :-
1. rooted android phone
2. you are aware of the port that RIL use for i/o operation.
3. to check which port is being used by RIl use `getprop rild.libargs`
To run AT command from ADB use:
echo -c "AT\r\n" > /dev/smd11
PS: smd11 is port used by RIL.This varies from device to device.
ALso to run AT commands from android application check this tutorial
http://tech-papers.org/executing-at-commands-android-application/
Kind of a combination of the above. We got it working with 2 terminals on a Pixel 4 XL.
On one we did:
cat /dev/smd7
in the other:
echo "AT\r" > /dev/smd7
The output shows up in the first terminal
Notes:
Have to be root!
None of the discovery mechanisms worked for us, so we blindly called into smdX until we got a response from "AT\r".
echo automatically adds a \n, so adding it is redundant.
I'm planning to build an automated system for deploying an Android build to various devices, in order to make development for multiple platforms a bit more comfortable. Is there a way to get the sdk version of a connected device through android shell or adb?
There will be a computer to which several test devices is connected, and I was planning to write a script which will fetch the correct build for each of those from a build-server, install the different apks on their respective devices, launch them and collect log info, to be made available through some other program whose specifications are beside the point.
The point is that I need to know the sdk version each device is running to install the correct apk, and I was hoping I could get this through adb, but I can't seem to find a way to access it short of building a tiny app, compatible with all versions, whose sole purpose would be to output android.os.Build.VERSION.SDK or similar somewhere my script could read it.
you can use this command:
adb shell grep ro.build.version.sdk= system/build.prop
It will output something like this:
ro.build.version.sdk=10
adb shell getprop ro.build.version.sdk
Note #Tim: this works even on phones without grep support on all host OS :-). (i.e. on old phones where toolbox does not support grep you you need to have busybox on your phone).
I also discovered a way to get the exact version of Android e.g. 4.2.2 based on the following web article http://xayon.net/looking-for-android-version-with-adb/ You need to be using a unix-like operating system - Linux and Mac OSX are fine, and windows users can use cygwin or equivalent.
At a command line:
echo version=$(adb shell getprop |awk -F":" '/build.version.release/ { print $2 }')|tr -d '[]'
Here is the result for my Nexus 4:
version= 4.2.2
I think you can by accessing the device with adb shell - change directories to position you at system and do a cat of build.prop. Here you will find for instance, ro.build.description=google_sdk-eng 2.2, ro.build.version.release=2.2 etc
I keep reading tutorials where I'm supposed to enter something into the ADB command line and that it's in my Android sdk/platform-tools. So I find it, click on it, and a black screen comes up for about 2 seconds and while it's up, it scrolls through a bunch of text. So how am I supposed to use this "adb"?
It is called the Android Debug Bridge, and the Android Developers Site documentation does a better job of explaining it than I can:
http://developer.android.com/guide/developing/tools/adb.html
If you are looking for the adb command line, navigate to <sdk>/platform-tools/ and run
adb.exe shell
from the command line.
Pretty sure that is well documented since day 1 on the Android Debug Bridge
Android Debug Bridge (adb) is a versatile command line tool that lets
you communicate with an emulator instance or connected Android-powered
device. It is a client-server program that includes three components:
A client, which runs on your development machine. You can invoke a
client from a shell by issuing an adb command. Other Android tools
such as the ADT plugin and DDMS also create adb clients. A server,
which runs as a background process on your development machine. The
server manages communication between the client and the adb daemon
running on an emulator or device. A daemon, which runs as a background
process on each emulator or device instance.
So plain old English, ADB can be found on %ANDROID_HOME%/platform-toos/, and it's this magical command line that allows you to comunicate with your mobile device, either a physical or a Virtual device (AVD), so whenever you deploy you are passing the application through the device thanks to the ADB on a specific client port on your computer to the daemon port on the device.
Interesting things you can do with it?
Logcat: ./adb logcat allows you to see the log trace of each proces.
Install: ./adb install allows you to install apk to the device.
Killing:./adb kill-sever
Starting:./adb stat-server
Enter SQLite3: adb -s your_device shell
Use the monkey: adb shell monkey -v -p your.app.package 500 to
generate random events
And a lot more! Read the documentation it's beatiful and self-explanatory.