My problem is as follows:
I would like to make an application to list the sms conversation using C# and AT Command ... (not Android)
The Android/iOS smartphone will be connected by USB cable.
is it possible ?
any ways to help me
Provided the phone implements a serial USB interface that speaks AT commands (Communication Device Class (CDC) Abstract Control Model (ACM)), then yes this is possible.
The command to read SMS messages is AT+CMGR and it is standardized in the 3GPP specification 27.005. For reading1 SMS messages there no special handling other than the normal AT command response parsing (never use sleep/delay/etc).
The sms commands operates in one of two modes, Text mode (optional) or PDU mode (mandatory). Text mode is simpler but does not provide all the meta information that PDU mode does. Depending on the phone or what you want to display and parse you might be required to use PDU mode.
Parsing the hexadecimal binary response you get in PDU mode is very far from trivial, and you most certainly want to use a library for this rather than trying to write parse code yourself (at least when your experience is starting on not knowing about the relevant commands and not having read V.250, 27.007 and 27.005 before).
1For sending you must wait for `"\r\n> " before sending the payload, see the first part of this answer.
I'm trying to reproduce an ATT packet being sent to a Bluetooth LE device already connected to a phone.
Is this even possible?
I've figured out how the packet should look like, I'm just not able to wrap my head around GATT and how it translates to ATT in this specific case.
The wireshark dump looks like this:
localhost () remote () ATT 26 Sent Handle Value Notification, Handle: 0x0035 (Unknown)
Bluetooth Attribute Protocol
Opcode: Handle Value Notification (0x1b)
0... .... = Authentication Signature: False
.0.. .... = Command: False
..01 1011 = Method: Handle Value Notification (0x1b)
Handle: 0x0035 (Unknown)
Value: 0a0b313233343536373839303132
I've already figured out that the actual application payload here starts after the handle 0x0035, with 0x0a 0x0b being some custom control characters and everything afterwards a number (123456789012), exactly as I expected it to be.
How do I translate the "handle" to the GATT protocol? Is this done in Android GATT via UUIDs? If I loop over all services on that device a get a bunch of services, loads of characteristics, descriptors and I'm lost.
Oh, what I forgot to mention: None of the services and characteristics I get seem to be related to the handle 0x0035.
Is "getInstanceId" supposed to return the handle that will be used? Writing to writable characteristics on that device lead to Wireshark showing the handle value corresponding to the getInstanceId.
first thing you have to know is that in Android you can't use the Handles direktly as a developer. You have to deal with the UUIDs. in Wireshark when you have a look at the ATT Protocoll you should be able to see the UUID of the service and the characteristic when opening the Handle drop down. With this Information you should be able to detect the UUids you need.
https://developer.android.com/guide/topics/connectivity/bluetooth-le shows you how to send a value to a notification. In general you can use Constants for example to ebanle notifications. I guess if your server requires specific bytes you should be able to send them the same way.
Well, after inspecting logs and docs a little more I came to the conclusion that the remote device (which should provide serivces) here is actually using a server on the local host and this is a value notification sent from the host to the remote.
For some work I'm doing, I want to have an emulated GSM modem which will communicate with an Android-x86 virtual machine over a Unix socket. The VM should see the emulator as a real modem and use it to send SMS (as the first pass of functionality).
So far, I've put something together which handles some AT commands and just replies "OK" to all the rest. For some commands, like "AT+CRSM", I just have a table of responses gathered from running the official Android emulator and looking at the radio log. For others, I maintain some state and construct answers; those commands include:
CFUN?
CPIN?
CGREG?
CGREG?
COPS?
CGREG=
CREG=
CPIN=
COPS=
CRSM=
CSMS=
CGSN
CIMI
CSQ
Android will boot, and send commands to my emulated modem, which answers, however it doesn't seem to be fully functional. Android doesn't detect any radio signal strength, for instance, just showing an "x" in the signal bar.
Does anyone know of a similar project, or just what AT commands are absolutely necessary to get some basic functionality?
Well, I'll answer another of my own questions, it's easier that way.
I ended up implementing an emulator which maintains a little bit of state, such as whether or not unsolicited CREG and CGREG messages are enabled, the network registration status & network name format (for the COPS command), and a message reference counter for SMS.
It supports the following commands:
CFUN?
CPIN?
CGREG?
CREG?
COPS?
CGREG=
CREG=
CPIN=
COPS=
CRSM=
CSMS=
CMGS=
CGSN
CIMI
CSQ
All other messages just get an "OK" response.
With the stock AOSP Android source running in an emulator with the "-radio unix:/tmp/phone" switch, I can send SMS messages and decode the binary PDUs into real messages. I will continue to add functionality so SMS messages can be injected back to Android, and hopefully open-source the code at some point.
I would like to know high level idea of how Android Modem code will call/pass message to Android application layer. Say we take SMS for example. If network sends SMS and Modem (say Qualcomm C code parses it) how is it transmitted to Android Application layer?
Is there always a JNI call happening? as interface between modem and Android? Can you please share the information with us. Thanks
In almost all android source base as found in the AOSP/CAF/CM source (Android Open Source Project, CodeAurora Forum, Cyanogenmod respectively), will have C code called the rild, (Radio Interface Layer Daemon). This is commonly found within the /hardware/ril of the source tree.
This daemon runs from the moment Android boots up, and creates a socket called /dev/socket/rild and /dev/socket/rild-debug. There will be a proprietary library coming from Qualcomm, HTC, that gets dynamically loaded at run time upon boot. It is that proprietary library that in turn, communicates to the radio firmware. And the rild's hooks for the call-backs into the proprietary library is established there and then.
At the rild layer, via the aforementioned socket, is how the Android layer (found in the source tree, frameworks/base/telephony/com/android/internal/telephony/RIL.java) communicates.
On the Java side, it opens the socket for reading/writing, along with establishing intents and setting up delegates for broadcasting/receiving events via this socket.
For example, an incoming call, the proprietary library, invokes a callback hook as set up by rild. The rild writes standard generic AT Hayes modem commands to the socket, on the Java side, it reads and interprets the modem commands, and from there, the PhoneManager broadcasts CALL_STATE_RINGING, in which Phone application (found in the source packages/apps/Phone) has registered a receiver and kickstarts the User interface, and that is how you get to answer the call.
Another example, making an outgoing call, you dial a number on Android, the intent gets created and which in turn the PhoneManager (This is the root of it all, here, cannot remember top of my head, think its in frameworks/base/core/java somewhere in the source tree) receives the intent, convert it into either a sequence of AT Hayes modem commands, write it out to the socket, the rild then invokes a callback to the proprietary library, the proprietary library in turn delegates to the radio firmware.
Final example, sending text messages, from the Messaging (found in packages/apps/Mms source tree) application, the text you type, gets shoved into an intent, the PhoneManager receives the intent, converts the text into GSM-encoded using 7-bit GSM letters (IIRC), gets written out to the socket, the rild in turn invokes a callback to the proprietary library, the proprietary library in turn delegates to the radio firmware and the text has now left the domain of the handset and is in the airwaves somewhere... :) Along with sending a broadcast message within Android itself, provided that READ_PHONE_STATE permission is used and specified in the AndroidManifest.xml.
Likewise conversely, when receiving a text message, it is in the reverse, radio firmware receives some bytes, the proprietary library invokes the callback to the rild, and thus writes out the bytes to the socket. On the Java side, it reads from it, and decodes the sequence of bytes, converts it to text as we know of, fires a broadcast with a message received notification. The Messaging application in turn, has registered receivers for the said broadcast, and sends an intent to the notification bar to say something like "New message received from +xxxxxx"
The intents are found in frameworks/base/telephony/java/com/android/internal/telephony/TelephonyIntents.java
That is the gist of how the telephony system works, the real beauty is, that it uses generic AT Hayes modem commands thusly simplifying and hiding the real proprietary mechanisms.
As for the likes of Qualcomm, HTC, forget about it in thinking they'd ever open source the library in question because the radio telephony layer is embedded within the S-o-C (System on a Chip) circuitry!
Which is also, as a side note, why its risky to flash radio firmware, some handsets provide the capability to do it, flash the wrong firmware (such as an incompatible or not suitable for handset), kiss the handset good-bye and use that as a door stopper or paper-weight! :)
It should be noted, that there is zero JNI mechanisms involved.
This is from my understanding of how it works, from what I can tell is this, the radio firmware is loaded into a memory address somewhere where the linux kernel has reserved the address space and does not touch it, something like back in the old PC days when DOS booted up, there was reserved addresses used by the BIOS, I think, its similar here, the addresses marked as reserved are occupied by the firmware, in which the proprietary radio library talks to it - and since the library is running in the address space owned by the kernel, a lá owned by root with root privileges, it can "talk" to it, if you think of using the old BASIC dialect of peek and poke, I'd guess you would not be far off the mark there, by writing a certain sequence of bytes to that address, the radio firmware acts on it, almost like having a interrupt vector table... this am guessing here how it works exactly. :)
Continuing from the explanation by t0mm13b, When we talk about a smartphone, think of 3 layer operations wrt to SMS/Calls.
RIL (User level) <-> AP <-> CP
AP : Application Processor(Where your Android OS runs. Think of games, songs, videos, camera etc running on this processor)
CP : Cellular Processor (Which actually deals with Air-interface for incoming/outgoing calls/sms, interacts with Network Tower etc ..)
Now let say some data is received at CP side (It could be internet data/sms/call). Now there are certain logical channels between AP and CP. So CP will push the data received to a corresponding channel based on type of data. This data will be received by AP. AP will send this data back to RIL/App. RIL will decode this data (specially call/sms data). Based on that gives notification to User about SMS/Call.
Can anyone give me an idea on how to read the values from the OBD II Bluetooth adapter in an android application.
I want to start with scanning for the bluetooth devices from my android application, then after bluetooth device is found, how would I interact with it and get the values from it?
You should start by reading this http://developer.android.com/guide/topics/wireless/bluetooth.html
it contains step by step procedure .
add required permissions,
make a bt adapter,
then find paired/unpaired devices
I used the BluetoothChat Application and was able to get some basic communications, I am not moving into data logging. You can use this application to have a sort of instant messenger conversation with your ECM.
What particular dongle are you using?
Do you know what protocols are in use within your vehicle?
Download the BluetoothChat sample application -
They will have already handled the intricacies of the connection for you, you will have to change the UUID in order to connect with your device - 00001101-0000-1000-8000-00805F9B34FB
Read up on your particular dongle, some require the return character to be sentat the end of every command "\r"
This should get you started!
Once you have made the Bluetooth connection using the android bluetooth api, use the transport to send and receive data via the Bluetooth channel.
This is new developer resource document:
https://developer.android.com/guide/topics/connectivity/bluetooth.html
The general workflow of the application functionality should go like this:
1) connect to the OBDII adapter through Bluetooth;
2) initialize OBDII adapter with AT commands;
3) continuously get data from the vehicle through issuing the corresponding PID codes.
This article also may be helpful.
http://blog.lemberg.co.uk/how-guide-obdii-reader-app-development