In previous versions of android we could block SMS by using following code:
<receiver android:name=".broadcastreceivers.OnSMSReceived"
android:exported="true" android:permission="android.permission.BROADCAST_SMS">
<intent-filter android:priority="1000">
<action android:name="android.provider.Telephony.SMS_RECEIVED"/>
</intent-filter>
</receiver>
and in broadcast receiver, abortBroadcast() function prevent SMS from going to inbox.
But this method is not working in kitkat as, from Kitkat SMS will only be received by default SMS app. Is there any workaround to create SMS blocker app in kitkat?
You should read this page: http://android-developers.blogspot.com/2013/10/getting-your-sms-apps-ready-for-kitkat.html
A change was introduced in KitKat that only allows one application at a time (the default SMS app) to have write permissions on the SMS DB and to be able to consume it.
You have 2 ways of solving your problem:
Follow Google advice on how to request the user to switch the default SMS application to your application during the time when you need to perform your changes (and once you finish doing it, allow the user to switch back to the original default SMS app).
Find a temporary hacky way to do what you need to do. As a hint, there is a hidden API: AppOpsManager#setMode that you could potentially exploit in order to give your application write permissions (OP_WRITE_SMS), head over to this XDA page to learn more about it: http://forum.xda-developers.com/showthread.php?t=2551072
Needless to say, any hacky solution is just temporary as a private/hidden API could change at any moment. It is strongly encouraged to implement what Google advised us to implement which again is described here.
you can check that your application is a default SMS application or not. for this purpose see this link. you can get the package name of default SMS app and check with your name, if equal with each other then you can block SMS with Delete from inbox. this should be worked for you.
I know this is an old question, but here's a possible solution to KitKat SMS blocking:
http://superdupersms.com/
Since it isn't a technical solution but rather a product based solution, it's possible this should be a comment and not an "answer" - and I am involved in the development.
But I haven't found any other solution that allows other apps to interact with the SMS database like they did prior to KitKat - which directly addresses the question. This solution allows a non-default SMS app to block SMS.
Related
Since API 21, Google has been adding features to android.telecom in general, especially by implementing more members of TelecomManager and the addition of InCallService. This last one is is supposed to allow non-system, 3rd-party apps to provide and replace the functionality of the system Calls app in-call screen - the Window that pops up and allows action on EXTRA_STATE_OFFHOOK or EXTRA_STATE_RINGING broadcasts (i.e. incoming and outgoing phone calls).
Currently, only this screen has full control of ringing and active calls and associated system callbacks with fine-grained information, by means of the root-restricted MODIFY_PHONE_STATE permission and a lot of secured AOSP code not even accessible by reflection. It's notably one of the most changed pieces of code in different manufacturers' ROM flavours, together with the launcher, contacts and camera.
This is all very pretty but...
How do you actually develop a 3rd-party InCallService?
Namely:
How do you get notified about, and acquire instances of GSM Calls
How does one answer these calls
What is the life-cycle of the callbacks on this class
Does Google provide any actual tutorial for this that I haven't found
I won't ask answers for all of these at once, but any one answer probably associates to the other questions. This is broad but intrinsically it needs to be: there's no example on the web I've stumbled upon other than AOSP-code, and that code is based on the assumption of root-privileges, which makes it unusable for 3rd-party app development purposes.
How do you get notified about, and acquire instances of GSM Calls
First, the user will need to select your app as the default Phone app. Refer to Replacing default Phone app on Android 6 and 7 with InCallService for a way to do that.
You also need to define an InCallService implementation the system will bind to and notify you about the call:
<service
android:name=".CallService"
android:permission="android.permission.BIND_INCALL_SERVICE">
<meta-data
android:name="android.telecom.IN_CALL_SERVICE_UI"
android:value="true" />
<intent-filter>
<action android:name="android.telecom.InCallService" />
</intent-filter>
</service>
There you should handle at least onCallAdded (set up listeners on Call, start your UI - activity - for the call) and onCallRemoved (remove listeners).
How does one answer these calls
If the user wants to answer the call, you need to invoke the method Call#answer(int) with VideoProfile.STATE_AUDIO_ONLY for example.
What is the life-cycle of the callbacks on this class
Check out Call.Callback for events that can happen with a single call.
Does Google provide any actual tutorial for this that I haven't found
I don't know about Google, but you can check out my simplified example https://github.com/arekolek/simple-phone
Follow the advice from the second comment of Replacing in call app. In addition you need a service that implements the InCallService interface. When a call arrives the onCallAdded(Call call) method will be called, giving you a reference to the call object.
<service
android:name=".InCallServiceImplementation"
android:enabled="true"
android:exported="true"
android:permission="android.permission.BIND_INCALL_SERVICE">
<meta-data
android:name="android.telecom.IN_CALL_SERVICE_UI"
android:value="true" />
<intent-filter>
<action android:name="android.telecom.InCallService" />
</intent-filter>
</service>
Once you have the call object, answering it's as simple as call.answer(). I suggest that when you get the stuff above working, run a couple of test calls to get to know when the different callbacks are invoked.
Regarding tutorials, I couldn't find any when I was looking into this, but that was over a year ago...
Hope this helps!
I guess Google must've read this question, because apparently on Android 8, a new permission finally allows answering calls through a 3rd party dev-facing permission.
android.permission.ANSWER_PHONE_CALLS (...) allows apps to answer
incoming phone calls programmatically
No details yet though, since the documentation for API 26 hasn't been released yet. I'll make sure to update this answer when they do.
EDIT: user arekolek provided an answer that works perfectly on the original API version of this question (at the time of asking, API was 23, even though the question mentions API 21), thus he gets the tick for right answer. Refer to his answer if you want to implement an incall screen that targets minimum SDK of 23. Note you might need API-dependant code or compat library tweaks if you want it to work on more recent APIs that deprecate (or restrict) usage of the provided sample code. the github repo works as I initially intended.
I would recommend you to see this project to build a dialer app for Android.
https://github.com/HiddenPirates/Dialer
In Android, if I send an intent from my app using implicit intent, and there are two services which have a matching intent filter, which service will get invoked ?
I know for activities, the user will be asked a choice through a pop up window. How does Android make the decision in case of services ?
Thanks.
Quoting myself:
In addition, what happens if there are two (or more) services installed on the device that claim to support the same <intent-filter>, but have different package names? You might think that this would fail on install, as happens with providers with duplicate authorities. Alas, it does not. Instead, once again, the first one in “wins”.
So, if we have BadService and GoodService, both responding to the same <intent-filter>, and a client app tries to communicate to GoodService via the explicit Intent matching that <intent-filter>, it might actually be communicating with BadService, simply because BadService was installed first. The user is oblivious to this.
Moral of this story: don't use implicit Intents with services.
They will look to the priority :
<intent-filter android:icon="drawable resource"
android:label="string resource"
android:priority="integer" >
. . .
</intent-filter>
I arrived here because I am using Braze (was appboy) to deliver FCM messages to my app using their AppboyFirebaseMessagingService class. I now need to deliver custom events coming from my backend to my app. At first I thought I should build a new service and add it to the AndroidManifest next to the Braze service. Turns out that won't work as described by #CommonsWare.
What does work is to make a new MyFirebaseMessagingService class that is a subclass of AppboyFirebaseMessagingService and mention the MyFirebaseMessagingService in the AndroidManifest. This way both classes will see all messages. I'll have to add logic to filter for just my messages and ignore the Braze messages.
I want to create an app that stores a timestamp into the database when I scan my work-batch which contains an NFC tag. This will be done via an IntentService without starting an activity. After a second scan another timestamp will be stored into the database via the IntentService. No activity has to be started. A notification will be enough. The activity can be started manually by the user to see the info.
I have read that there are a lot of different tag technologies. But I like to make my app a bit more universal. So I don't know which kind of NFC tags my clients are going to use. I could listen for all the different tags and let the user pair a tag with a certain task.
This is fine unless there is one NFC app on the phone. But I have another app which uses NFC. And when I scan a tag Android shows me a selection dialog which app may handle the tag. But I don't want this every time I scan a tag. I want to use both apps so I dont select a default for the tags.
So the question is, How can I scan a tag and route it to the right app. So tag A will be handled by app A and tag B by app B without getting the selection box every time.
I was thinking what the best option should be or maybe somebody has a great idea how to solve this.
I have taught of a couple of different solutions:
Use only writable NDEF tags and add a Android Application Record (AAR) to it. So it will launch the right application after scanning. (If there is no NFC app active in the foreground) this will mean that the user is restricted to a tag technology and needs to write it before using.
Let the application listen for all NFC tags and if a tag is not paired to a task forward it to the system again so that other apps can handle it. (Don't know if this is possible)
Write a app which listens for all NFC tags and let the user decide which tag will be send to which application. So when a new tag is received by the application it asks the user which app may handle the tag and stores the default for this specific tag [by ID or something] into a database. So the next time it will route the intent to the default application for this tag. (Or is there already something like this?)
Hopefully this question is a bit clear. Else I'll try to clarify it a bit more if you like ;-)
I really like to hear what you think about this. Or maybe you have some good suggestions? Please let me know.
Thanks in advance.
I've successfully use an application specific URL scheme for this. Let's assume your URL scheme is "kuiperstimestamp".
The tag then should contain a URL like:
kuiperstimestamp://ts/20130506T034536.293
You then create an intent filter for your service that includes a data element:
<intent-filter>
<action android:name="android.nfc.action.TAG_DISCOVERED" />
<category android:name="android.intent.category.DEFAULT" />
<data android:scheme="kuiperstimestamp" />
</intent-filter>
Since the intent filter is rather specific, you don't get the app selection dialog (unless another app or service has the same specific intent filter which is unlikely).
This approach is less Android specific than using an AAR.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
BroadcastReceiver + SMS_RECEIVED
Lets say i have an application i want to launch every time my phone receives a specific text message, a keyword for example. Can i do this if my application is not running? What' s a good way to do it?
I have never tried this before and i want to run an application on one phone which will send a specific text message to another phone (done so far), then the 2nd phone would start an application when the message is received (after checking the message to see if its the keyword).
You need to write a BroadcastReceiver with the following intent filter
<intent-filter>
<action android:name="android.provider.Telephony.SMS_RECEIVED" />
</intent-filter>
You'll need to create an AlarmManager for this with a BroadcastReceiver in order to receive data when your application is not running, I believe.
Although this may not be possible, as it could be considered a security risk to read the contents of a user's text messages... this would require some nasty permissions, and your users may not want to use the software because of that. Try taking a look at some of the Amazon free app of the day reviews to see how bad this can be for your app.
Other than that, you should be able to use the classes stated above in order to implement this. Let me know if this isn't clear and I'll try to expand upon it.
EDIT:
My mistake, a more appropriate way to handle this would be through a Handler with a background Service. I haven't personally used this myself, so I can't tell you much more than the documentation. Try reading the documentation and looking at the examples :)
I'm a newbie on Android development platform.
Can a third party application (say the one I'm developing) send SMS messages?
I believe we do not have access to default text messaging app. Therefore I plan to develop one on my own, which will read words used and process such texts before delivering to receiver. I would like to know if there are such APIs which allow to send text messages.
Here is a simple snippet that might help:
SmsManager smsMgr=SmsManager.getDefault();
String destination="9999119911";
String msg="Hello World";
smsMgr.sendTextMessage(destination,null,msg,null,null);
Don't Forget to add
<uses-permission android:name="android.permission.SEND_SMS"/>
to AndroidManifest.xml
Testing :
You can send SMS from one instance of emulator to another ,to do that ,simply specify the port
number of the other instance as destination .
to check the port number :
$ /opt/android-sdk/platform-tools/adb devices
http://thinkandroid.wordpress.com/2010/01/08/sending-sms-from-application/
I think this is what you are looking for. The second method described in the article does not need any additional permissions, but it requires that the user types the message. I don't think there is a way to send an SMS without the permission.
A good place to start is here http://developer.android.com/reference/android/telephony/SmsManager.html
You need to use the SmsManager class, if you want to include SMS capability in your app.