We are working on a app based on Google's Rich Messaging Platform (RCS) and I'd like to ask some specific questions pertaining to how SMS is delivered into Android devices.
Questions for the matter of understanding:
Are SMS messages delivered into the Android OS or the messaging app?
Are SMS messages being pushed (ie. Push Notifications) into the Android OS or messaging app? If not, is it pulled - and how?
Do MMS work the same way as SMS, in terms of how messages are delivered?
Important Question:
If we are developing an RCS app to replace SMS. Is it possible to deal with receiving SMS directly? That is, interaction with SMS would completely bypass the Android OS and/or another (default) messaging app.
EDIT - added the following questions:
This post says we can listen to incoming SMS/MMS messages. So, here's a question:
Can our app be the only sole app to listen for SMS/MMS messages?
If the answer to the above question is no, then (after the user reads the message on our app), can our app send a message to the other SMS messaging app(s) to remove the batch count and set the message to read?
If our app is NOT using Direct Boot, will SMS/MMS be lost since they cannot be delivered, whether or not our app is the sole SMS/MMS app?
And, this question for the matter of understanding:
From what I understand now is the SMS/MMS are part of the telephony system, while RCS is NOT. Could you confirm my understanding is correct?
Thanks!
To the best of my knowledge, this is how the SMS works on Android:
Are SMS messages delivered into the Android OS or the messaging app?
SMS messages are sent to the Android OS as they are part of the telephony/cellular system. They are definitely not pushed to any particular messaging app as the incoming message comes from the cellular provider to the device (aka the OS/firmware) directly. The messaging app a user interacts with is simply a "front" for displaying and interacting with the user to send/show messages at they are received. You can actually change the default messaging app on Android which further demonstrates that SMS is actually part of the OS.
Are SMS messages being pushed (ie. Push Notifications) into the
Android OS or messaging app? If not, is it pulled - and how?
Much like an incoming phone call, SMS messages are "pushed" to the device but not in the way you may be familiar with like Push Notifications (i.e. GCM). The concept of a Push Notification is something that exists on the IP layer; that is, it's a service that runs on the Internet. The kind of push a device receives for SMS messages is part of the telephony system. This is why, for instance, devices can still receive SMS with mobile data turned off but can't receive notifications for a Facebook message.
Do MMS work the same way as SMS, in terms of how messages are
delivered?
Yes, they work essentially in the same way as described above except they have some additional protocol for how they handle the data that is received from the cellular network to fetch things like images. The data is still transmitted on this telephony network and not over Internet (for the most part). There are implementations now of MMS that may piggyback off the Internet to fetch and load images quicker but that may be carrier specific.
If we are developing an RCS app to replace SMS. Is it possible to deal
with receiving SMS directly?
It depends what you intend to do. You won't be able to fundamentally change the SMS protocol on the telephony network as this is not within your control as an application. However, you can create an app to monitor and listen for SMS message as they are received in the OS. You can check out this post on how to do that. If you wanted to create your own RCS, you'd pretty much have to do this over the Internet. Services like WhatsApp have made clever use of combining both telephony SMS and standard Internet messaging to create a seemingly seamless experience. Without further context on what you're trying to build, I won't be able to provide more help.
In the end, you should just think of native SMS as being part of the phone. For further readings on how SMS works, I suggest the SMS Wikipedia page. I hope I was able to answer some of your questions!
Related
I want to create an app for Wear OS to replace the default Messages app for handling SMS/MMS messages. To start with, my app will get messages from the phone, relying on the phone to communicate with the cellular carrier. What does my replacement app need to do to send and receive SMS/MMS messages from the phone?
Can my app communicate with the default Google messaging app on the phone (so I don't have to write a phone app too)? Is that protocol/API documented somewhere?
Does my app need to register with the watch to become the default message handler and disable the default app? If so, how do I do that?
Is it possible to send SMS / MMS over wifi if the phone's carrier service is not working?
I have an app setup and it is sending and receiving text messages over the phone's data plan, but I want to send text messages over wifi instead. Right now it just fails over wifi.
Does anyone have experience with this?
To do that you would need to setup an sms/mms gateway from scratch https://en.wikipedia.org/wiki/SMS_gateway and I really doubt that's what you want to do.
It involves contracts with carriers and much more then just technical issues. As mentioned in a comment twillio is a pretty great way to get at it. There's a bunch of other options if you lookup sms web apis
https://www.twilio.com/ gives you a simple api to send sms/mms and more.
For the Android specific lib checkout https://www.twilio.com/docs/api/client/android
Currently, in order to push notifications to an android app on the android operating system, it appears the app needs to integrate Google Cloud Messaging (GCM) APIs. The App Server currently pushes data through GCM and GCM will push data to specific devices.
This is a silly question, but I was wondering if it is possible to replace GCM in this process? In other words, is it possible to have an alternative server as opposed to GCM? The motive is to hide the data from the GCM server.
Before:
App Server ==> GCM ==> Android App
New:
App Server ==> Custom Cloud Messaging ==> Android App
You can use app-directed sms/ port-directed sms.
Send sms from the server(SMS gateway) to a particular port on which your app will be listening.This sms will act as GCM message.
Using this approach you don't have to worry about long running service draining the battery. Also sms are almost real time and doesn't require internet connection.
However there are some phones don't support port directed sms.
For port directed sms you need to register a broadcast receiver something like below:
<receiver
android:name = ".SmsReceiver">
<intent-filter>
<action android:name="android.intent.action.DATA_SMS_RECEIVED" />
<data
android:scheme="sms"
android:host="*"
android:port="8095" />
</intent-filter>
The port directed sms does not appear in user's sms inbox if properly supported by phone.
Replacing GCM is actually not a trivial task. I would have to strongly advise against doing a long-polling mechanism as suggested earlier - the truth is that going down that path would be extremely expensive in terms of resources (battery life) and managing it would be a nightmare. There are going to be tons of error conditions that you're gonna need to address - from network drops to managing guaranteed delivery.
Full Disclosure: I work for Magnet Systems which has a product - Magnet Message - that provides these capabilities and more.
What we did was create a persistent socket to the server. (BTW, this is what GCM does as well as Apple's APNS). This socket is used to be able to "push" messages to the device. By understanding the connectivity on the socket, you'll understand the presence of devices and know if you can send messages to them.
Nevertheless, it's still a challenge to address things like pushing to an app that is offline or killed - and across platforms (probably don't want to forget the other 40% of iOS users) - so there are different challenges there. To address this, we send a "signal" via GCM to notify that there is a pending message and have a Broadcast Receiver that can go to our server and fetch the messages securely.
Since we allow you to deploy our server code in your environment, we don't have to see anything that you send. (Of course, we have a SaaS model as well).
At any rate, you can take a look at what we've done at http://developer.magnet.com. It's free to play with and we've got a bunch of open source stuff.
It is not recommended to bypass GCM since any other mechanism you might use will require a persistent connection from the phone to your server which will be a battery hog. GCM already has one connection open all the time so it should be reused as much as possible.
It is however understandable that you want to hide data from the GCM servers. In that case it should be simply encrypted. The Chrome team (which uses GCM) has decided to do the same (hide payloads from the GCM server) and perhaps their solution for encryption would work for you as well. You can see what they did in
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Intent$20to$20Ship$3A$20Push$20Messaging$20Payloads/blink-dev/Vga32co0YMQ/4i6qXvfeAwAJ
The same link contains a demo and the code for it.
Note that the purpose of those examples is to implement it in chrome which is not exactly what you want. However the actual encryption method could be reused for Android.
Not really a programming question, but I'm currently researching battery life and PUSH notifications on Android for an assignment.
I'm aware that third-party apps are able to use C2DM to be able to respond to PUSH notifications even while the phone is sleeping.
Besides responding to an SMS, is there any other way for third-party apps to listen for PUSH notifications without running as a service and keeping the phone awake?
How does the built in Exchange e-mail in ICS work? It seems that the phone is able to sleep even with an Exchange account set to use PUSH. Does this mean that the exchange service goes through Google's C2DM framework, or is it implemented in some other way? E.g. the phone has an idle connection directly with the given Exchange server but is still somehow able to sleep between incoming packets?
I am working on an application and one feature that would make it really useful is the ability to share some information, but the other device may not be expecting the data to be sent.
For example, if I am reading a really good book, and I realize that a friend may like it, I could use an application to send the data to him, so he could order the book from Amazon.
But, since he isn't expecting the data, I would hate for the application to be polling a server every so often, as that will be needlessly draining the battery.
Ideally it would be great if there was a way to make a phone call to the target device, send a data packet and end the call.
If it could be done and prevent the phone from ringing, then it would be very useful to me.
I am curious if there is some way to send data between devices without polling.
You can send them a message via facebook or email (e.g. here), or broadcast it with twitter.
These approaches - using an existing infrastructure for messaging - provide mechanisms for discovering your user's contacts / 'friends' and so on too.
Your can send and read SMS on phones if you have the correct permissions.
You could talk to Mashmobile who have a bigger platform that can do peer-to-peer between phones. You could imagine a hybrid that did both Mashmobile for Windows/Android/Symbian and Apple's push for iPhone users of your app.
On future phones, you could use C2DM (which is a application-specific messaging system overlay on gmail - the Android phone user has to have a Google account etc)