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
Related
Background
I just noticed some functions of NotificationManager that handle a class that's called AutomaticZenRule :
https://developer.android.com/reference/android/app/NotificationManager.html#addAutomaticZenRule(android.app.AutomaticZenRule)
and others...
The problem
Looking at the docs of AutomaticZenRule, it still doesn't tell much about what it is, and what can it be used for:
Rule instance information for zen mode.
What I tried
Searching the Internet, I can see just in a Commonsware blog post, that they wonder what it is:
It is unclear what AutomaticZenRule is ...
There is practically nothing more that I've found about it. Not "zen mode" and not "AutomaticZenRule".
The questions
What is "zen mode" ?
What is "AutomaticZenRule" , and what can I do with it? How is it related to notifications?
Is there anything special on Android N, that this API was added on this version?
Is there a sample for using it?
Zen Mode is just another name for Do Not Disturb (DND) mode. Android can activate DND mode based on rules. These rules can be provided either by the system, or by a third-party app.
In the following screenshot you can see two system-provided rules, together with a "Driving" rule provided by the third-party app "Pixel Ambient Services":
AutomaticZenRule is there to integrate your own rules into the Android system. To integrate your own rules, you have to follow these rough steps:
Make sure that you have sufficient permissions to access the DND policy (android.permission.ACCESS_NOTIFICATION_POLICY). See NotificationManager.isNotificationPolicyAccessGranted() for details.
Add an activity for your rule:
<activity android:name="MyRuleConfigurationActivity">
<meta-data android:name="android.service.zen.automatic.ruleType" android:value="My Rule" />
<intent-filter>
<action android:name="android.app.action.AUTOMATIC_ZEN_RULE"/>
</intent-filter>
</activity>
Android will show your activity whenever the user wants to create or edit a rule of the specified rule type. In the latter case, Android will supply the ID of the existing rule in NotificationManager#EXTRA_AUTOMATIC_RULE_ID. To propagate changes in your activity back to android, you need to construct an AutomaticZenRuleinstance and call NotificationManager.addAutomaticZenRule / updateAutomaticZenRule.
After that, you can tell Android that the conditions for your rule are currently satisfied / not satisfied by calling NotificationManager.setAutomaticZenRuleState.
From digging in into the other documents available, i was able to understand ZenMode to some extent(although it can be my own version and not the correct one).
What my understanding is as follows -
Zen Mode is the Do not Disturb mode which now in latest updates can be enabled automatically which depends on factors such as late time of the day, etc. AutomaticZenrule can be used by applications who want their notifications to not be masked or suppressed when in do not disturb mode.
For this your application should make request to policy access by sending the user to the activity that matches the system intent action ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS.
If user has granted access to notification policy for your app, then you will be able to set a priority notification even in do not disturb mode. AutomaticZenrule thus plays a vital role to state the system that the application's notifications not be suppressed.
Although, i dont have a running sample code for it, i guess it should be on similar lines like the enabling device admin code or requesting a permission use case.
Thanks to you i got to read something new :)
Android API level 24 introduces a new Service called the CallScreeningService. The documentation says that the service can by implemented by the default dialer to screen incoming calls. I would like to implement this service in my own app, preferably without creating an entire dialer app, but a simple naive implementation seems to be ignored by the OS when an incoming call happens.
AndroidManifest.xml snippet:
<service android:name="com.example.callbouncer.CallService" android:permission="android.permission.BIND_SCREENING_SERVICE">
<intent-filter>
<action android:name="android.telecom.CallScreeningService"/>
</intent-filter>
</service>
CallService.java:
// imports...
public class CallService extends CallScreeningService {
#Override
public void onScreenCall(Call.Details callDetails) {
CallResponse.Builder response = new CallResponse.Builder();
Log.e("CallBouncer", "Call screening service triggered");
respondToCall(callDetails, response.build() );
}
}
There are no errors while building or installing this program, but the screening doesn't seem to be taking place. Have I done something wrong (like the manifest or missing implementations/overrides in the service) or is it just not possible? If it's not possible in a small app like this, will it be possible if I implement an entire dialing app and set it as the default dialer? Finally, if that's the case, is there anything preventing me from just forking the dialer out of the AOSP and adding my features to it?
As of Android 10 (API 29+), you can have a CallScreeningService without the requirement of also implementing an entire dialer app. Until Android 10, only the default dialer app's call CallScreeningService would be invoked.
https://developer.android.com/about/versions/10/features#call-screening
Don't get too excited though, because it's very buggy and does not work as the documentation says it does:
CallScreeningService#onScreenCall is called for known contacts
CallScreeningService#setSkipCallLog doesn't show blocked calls in the call log
My workaround for getting called for known contacts was to ask the user for contact access and check if the incoming caller was in the user's contacts. There is no workaround for the other issues at the moment.
I made a very basic screening app that declines all calls from numbers not in the user's contacts you can use an an example if you like: https://github.com/joshfriend/gofccyourself
Looking at the docs you linked to:
This service can be implemented by the default dialer (see
getDefaultDialerPackage()) to allow or disallow incoming calls before
they are shown to a user.
Don't think you can do this in a separate app (at least with the current interface: I'd expect in the not too distant feature it will be exposed).
We removed an SDK from our Android app (all class and method references) and pushed it to the play store, but forgot to remove the declaration for it from the manifest:
<service android:name="com.radiumone.emitter.location.LocationService"/>
Today we have one crash through Crittercism that didn't happen in regression testing in which an attempt is made to load this service. My research suggests the only way this could happen is if the service is exported by default, and that can only happen if the service contains intent-filters. Is this true, and if so, how do I find the intent-filters associated with a service? I can't find any contained in my AndroidManifest.xml; where else should I look?
Is this true
In an unmodified application, yes.
how do I find the intent-filters associated with a service?
They would be child elements of the <service> element in your manifest. If your element is as it is shown in the question, you have no <intent-filter> elements, and your service is not exported.
I can't find any contained in my AndroidManifest.xml; where else should I look?
There is no place else to look.
Today we have one crash through Crittercism that didn't happen in regression testing in which an attempt is made to load this service.
You may wish to ask a separate Stack Overflow question where you provide more details about the crash, to try to get our help in confirming your belief that somebody else is attempting to start or bind to your service. Perhaps you are misinterpreting the results.
I've implemented a WearableListenerService in both my main app and the companion Wear app. In the manifests, the service needs to be declared as android:exported="true" (or not declared at all and left to default to true) since it's started by Google Play Services. An exported service with no permissions can be called by any app on the system, but I can't find the correct permission to add to the service declaration to secure it. I've looked through the permissions on both the phone and the Wear device with pm list permissions but I don't see anything that looks like what I need.
Is there a permission that I can/should add to secure my services?
If not, is it a good idea to manually secure the service by checking the package name of the caller?
The best way to see how to implement a WearableListenerService on Android Wear is to look at one of the existing samples provided by the SDK. If you look at the DataLayer sample included at $SDK/samples/android-20/wearable/DataLayer it has a full implementation of what you are wanting to do.
If you look in the AndroidManifest.xml for the wearable side, you can see it has the following:
<meta-data
android:name="com.google.android.gms.version"
android:value="#integer/google_play_services_version" />
<service
android:name=".DataLayerListenerService" >
<intent-filter>
<action android:name="com.google.android.gms.wearable.BIND_LISTENER" />
</intent-filter>
</service>
For your security concerns ... When we declare a service in manifest and add a filter to it, it automatically becomes an exported service. So in general, other apps can bind to that service. In case of WearableListenerService, there is a security check that happens in the framework to make sure that the agent binding to that is Google Play Services so no one else can really bind to that service, unless the app developer exposes other intent filters in which case the intention is for others to access it.
So if you implement your code in the same way as the Wear SDK samples, your app should be secure and you do not need to worry about any extra permissions, etc.
Is there a permission that I can/should add to secure my services?
If not, is it a good idea to manually secure the service by checking the package name of the caller?
You don't need to worry about securing your WearableListenerService implementation with permissions or caller package checks. As #Wayne pointed in his answer: there is a security check that happens in the framework. This check is done in the WearableListenerService base class. You can find further security analysis of the Wearable SDK in the following article:
https://labs.mwrinfosecurity.com/blog/android-wear-security-analysis. Here is the quote from it:
The method pr() first checks if com.google.android.gms is Google
signed and then calls cU() to check if the calling process UID is for
the package com.google.android.gms (the Google Play Service package).
If the class is further decompiled, it can be seen that this security
check happens in each method exposed in WearableListenerService.
Unfortunately currently Lint checker produces false positive warning for the wearable listener service declaration whenever it doesn't contain BIND_LISTENER filter (which inclusion produces other warning since it's now deprecated and should be avoided):
Exported services should define a permission that an entity must have in order to launch the service or bind to it. Without this, any application can use this service.
This is certainly a bug in the security detector code (it just wasn't updated when BIND_LISTENER intent became deprecated). I've opened an issue regarding this on the Android bug tracker. Meanwhile to get rid of the warning one needs to add tools:ignore="ExportedService" to its wearable listener service declaration.
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.