I'm currently developing an application that needs to deal with SMS only if it is an SMS expected by the application (same behaviour as Whatsapp on registration).
I would like to abort the SMS Intent as it is not expected to appear in the SMS box.
My question is : I know that Google changed a lot about SMS behaviour in KitKat, and now, even if my SMS is well parsed by my application, the SMS also appear in SMSBox, even if I call this.abortBroadcast(); in my SMS broadcast receiver. So is there a way to avoid those SMS appearing in SMS box without having to develop a complete SMS application ?
For information, the priority is yet to 1000 (and I tried also with MAX Integer) in Manifest file for this Broadcast Receiver.
Hangouts uses the maximum possible priority (999 per the Intent-Filter docs) and therefore you cannot abort it on <4.4 releases. On 4.4+, only the default SMS app (blog post with details) can make changes to the SMS Provider (i.e., automatically delete the SMS).
You can't stop a message from showing in Default SMS application in kitkat. Checkout following links for details:
https://code.google.com/p/android/issues/detail?id=61684
http://android-developers.blogspot.co.uk/2013/10/getting-your-sms-apps-ready-for-kitkat.html
You can block SMS on Android 4.4 - 4.4.4 using
1)
Using AppsOpps setting
WRITE_SMS permission
Sms will be deleted in 10 seconds with notification about this sms.
As option you can block sound on receiving unwanted sms.
2) Set up your app as default sms app.
Related
So i want to write a PoC app for an idea that I have. One of the feature that my app would do is send a text message (and perhaps receive delivery notification). Its not going to be an SMS app. Just a service which might run in the background and sends sms on some particular interval, unattended (of course with user consent).
i remember in some of android api release, Google took the decision that you can only send receive sms if you have selected your app to be "default" sms app ? I don't remember exactly.
So the question is, can my app (as a service) send an sms and receive delivery notification while not being an SMS app ?
Whenever I try to Google this question, I find how to send sms example with SMSManager and the code to send the sms but no where i could find this answer.
So the question is, can my app (as a service) send an sms and receive delivery notification while not being an SMS app ?
Yes. Since KitKat, there has been the concept of a default SMS app, which is what I believe you're referring to.
The main difference in the way SMS are handled as of that version is that only the default SMS app has write access to the Provider, but any other app can still send and receive messages as usual. If your app is not the default, any messages it sends will automatically be written to the Provider by the system.
Furthermore, the SMS_RECEIVED broadcast can no longer be aborted, so you don't have to worry about some other app intercepting incoming messages before your app gets a chance to handle them.
I am working on an application in which i am sending an sms from a device to itself. Now i want to read it from my application. I know how to read it but i also read from the developer page that only one (default) sms application will be able to read the sms. If that's the case how can my application can read the sms that is sent by my application.
To Receive SMS i am using broadcast receiver which is registered in the manifest.xml.
-THANKS
...read from the developer page that only one (default) sms application will be able to read the sms.
Nope. Your app can still both receive and read incoming SMS in KitKat and above using the standard methods (barring any alterations to the standard behavior by the vendor). The changes to the SMS API are a little confusing, but it mainly boils down to the fact that non-default apps cannot write to the Provider. Any app with the RECEIVE_SMS permission can still get messages as they arrive. Also, this broadcast can no longer be aborted, so any and all Receivers registered to do so will receive it. Furthermore, any app with the READ_SMS permission can still read messages from the Provider. As mentioned, they just can't write to it to save messages or update their status.
As testimonial, my device runs KitKat 4.4.4, and I use it to send messages to itself all the time for testing, all from non-default apps.
I'm developing an application that works like an SMS BlackList / WhiteList. It is not a SMS application right now.
The goal is:
If the number is in Blacklist, it prevents the user for receiving / sending sms and it does not appear on his sms applications.
If the number is in Whitelist, the user can do everything he wants.
With some special cases, messages that have been blocked are stored in our database to be send after few hours;
To sum up my app needs to be able to:
Block SMS (before any other app can deal with it, like a popup sms app)
Send SMS
So far, the component works fine with android pre KitKat.
The idea is to deal with broadcast (for received sms) and observers (for sms to send).
By the way, the KitKat SMS handling is mainly different. As I know, we kind of need to be the default sms app to send message.
My questions are:
Do I really need to be the default SMS app to send / observe messages ?
Do I have to implement a kind of basic SMS app or is there another way to send SMS with SMSManager for example ? (http://android-developers.blogspot.fr/2013/10/getting-your-sms-apps-ready-for-kitkat.html)
Do I really need to be the default SMS app to send / observe messages ?
Do I have to implement a kind of basic SMS app or is there another way to send SMS with SMSManager for example ?
No. Any app with the SEND_SMS permission can still send messages using the SmsManager's standard methods, and the writes to the Provider will be taken care of for you, if and only if your app is not the default SMS app. If yours is the default, it is responsible for the writes.
Any app with the RECEIVE_SMS permission can still get the SMS_RECEIVED broadcast and read the message from the Intent. Also, the SMS_RECEIVED broadcast cannot be aborted, starting with KitKat, so there's no real way to block any app listening for that broadcast from receiving incoming texts, even if your app is the default. However, apps that are compliant with the recommended behavior of SMS apps in KitKat or above will disable any processing of incoming messages if they're not the default. That is, if your app is default, other apps shouldn't care about incoming messages.
After checking the Android SMS API, I still get confuse about the document explanation.
http://developer.android.com/reference/android/telephony/SmsManager.html
In the API, it mentioned that SmsManager.sendTextMessage(), it described as below:
Note: Beginning with Android 4.4 (API level 19), if and only if an app is not selected as the default SMS app, the system automatically writes messages sent using this method to the SMS Provider (the default SMS app is always responsible for writing its sent messages to the SMS Provider). For information about how to behave as the default SMS app, see Telephony.
So, does it mean that only in Android 4.4 and above, if the app is not default SMS app, then using sendTextMessage() will also add to content://sms/sent?
If the device is below 4.4, then app is responsible for adding to content://sms/sent for the message sent?
I tested on sendTextMessage() on Android 4.3 and 4.2.2, it will not write to SMS provider.
http://developer.android.com/reference/android/provider/Telephony.html
In the Telephony API document about
Creating an SMS app
Only the default SMS app (selected by the user in system settings) is able to write to the SMS Provider (the tables defined within the Telephony class).
I don't understand what the tables defined within the Telephony class?
I tested in Android 4.4.2(Nexus 5), use sendTextMessage() then then add insert the sent message to content://sms/sent. It is successful. The app is not default SMS app. It still can access to the SMS provider. So i don't understand the document explanation that only default SMS app is able to write to the SMS provider....
For deleting a sms message
In the below thread:
Delete an sms from inbox
Here, replied that to delete an sms, need to delete on "content://sms/conversations/".
But why not from "content://sms/inbox"?
Thanks a lot for your kindly response.
I have an app that has device admin rights. My app monitors received SMS's and passes the content through some logic. Can i change the default SMS app to my app programatically . My app checks for spam messages so it needs to read/write/update SMS db. I want a fix for kitkat.
I just noticed that the incoming SMS notification on my app are no longer notifications for new SMS that are received , but instead are "new Hangout message" notifications that are caused by hangouts receiving the incoming SMS. So my app is also not able to receive incoming text messages with SMS_RECEIVED.
Google's Android Developers Blog post about the new SMS API in Kitkat, said that nothing would change for apps using just SMS_RECEIVED and don't try to write the SMS to the SMS Provider.
1 I always believed that the SMS_RECEIVED broadcast is abortable. But the Android 4.4 APIs site says something different: "…when a new SMS arrives by listening for the SMS_RECEIVED_ACTION broadcast, which is a non-abortable broadcast…"
Can i change the default SMS app to my app programatically
Not directly. You can prompt the user to change the default SMS app.
My app checks for spam messages
Repackage your code as a library and license it to SMS clients.
So the Pebble app is also not able to receive incoming text messages with SMS_RECEIVED
Possibly the Pebble app is simply having other problems and is crashing before it notifies the Pebble. Or, possibly the Pebble app is updated for Android 4.4 and, since it knows it cannot stop the Hangouts notification, simply suppresses its own.
Google's Android Developers Blog post about the new SMS API in Kitkat,said that nothing would change for apps using just SMS_RECEIVED and don't try to write the SMS to the SMS Provider
That is not what this blog post says.
I always believed that the SMS_RECEIVED broadcast is abortable
This undocumented, unsupported broadcast had been an ordered, abortable broadcast through Android 4.3. That is no longer the case with Android 4.4, as you can tell by reading the aforementioned blog post:
Note that—beginning with Android 4.4—any attempt by your app to abort the SMS_RECEIVED_ACTION broadcast will be ignored so all apps interested have the chance to receive it.