1

I need to know when a certain intent (in my case ACTION_CALL and ACTION_CALL_PRIVILEGED which are called when the user or an app make a phone call) was sent without registering my activity to handle it.

I don't want to interfere with the normal handling of that intent, i.e. the activity that's supposed to handle it should still handle it the usual manner (in my case the OutgoingCallBroadcaster).

I read here a suggestion to drop the ACTION_CALL_PRIVILEGED intent and issue another one, but want to avoid it. Moreover, I don't want to use an activity for the ACTION_CALL and issue another since it will appear in the intent chooser as an option and I want it to be transparent to the user and to always work.

Also working with the ActivityManager object like this suggestion is not recommended for core logic as stated in the documentation of the getRecentTasks method.

Please tell me if this is possible in Android, and if so how.

Thanks, Amitai

Community
  • 1
  • 1
david-hoze
  • 1,045
  • 15
  • 31

1 Answers1

0

No. This isn't possible. If it were possible it would allow me to write an app that monitors a user's behaviour without him knowing it. ACTION_CALL is an Intent to launch an Activity. You can, of course, intercept this, but that is clearly not what you want to do.

There are broadcast Intents that are sent out during the "call" process. You can monitor these, but you'll have to register to listen for them. Since you indicated that you don't want to register any listeners you are pretty much out of luck.

Which is a good thing, because otherwise people would be able to write a "NastyWare" application.

David Wasser
  • 93,459
  • 16
  • 209
  • 274
  • Thank you very much for your answer, however I was only trying to avoid an infinite loop when I intercept the user's call using NEW_OUTGOING_CALL [this way](http://android-developers.blogspot.co.il/2013/05/handling-phone-call-requests-right-way.html), ask the user if they want to make it through our calling card, abort it and send a new call with a modified number (like Prefixer for example). If another app also uses this mechanism (like CSipSimple or Sipdroid) it may cause an infinite loop. I could prevent this if I could distinguish between the two intents, but you're right, it isn't secure. – david-hoze Jan 19 '14 at 09:18
  • So I would appreciate it if you remove the part about me writing "NastyWare", since it is not true, I was only unaware of this security issue.. – david-hoze Jan 19 '14 at 09:22
  • I've altered the text of my answer so as not to imply that you are writing "NastyWare". – David Wasser Jan 19 '14 at 11:46
  • I don't really understand the infinite loop problem. There are 2 ways to handle this: 1) Abort the call, make a new call with a new number. When you intercept the call again, you can recognize that the number-to-call is yours and just pass it on. 2) Instead of aborting the call, just modify the number and let the broadcast chain continue. The call will be made with your modified number. – David Wasser Jan 19 '14 at 11:52
  • Thanks for editing :). I'm using way no. 1 (I need to present a prompt), and indeed ignore the next call. However, CSipSimple then catches the broadcast and does the exact same thing (when choosing the "Use Mobile" option), and I'm getting called again, without knowing CSipSimple started the call and not the user. Now if the user chooses to keep the number the same CSipSimple knows how to ignore it again, and so do me the next time and the call is made. However, if the confounded user selects to modify it again (access no.+orig+'#') CSipSimple appears again and so on infinitely. – david-hoze Jan 20 '14 at 10:07