The app I am developing needs to know when someone presses the End Call button. It doesn't need to alter the button's function at all. It merely needs to know when it is pressed. I would just like to know if this is possible and how to do this?
I have been looking at the KeyEvent class, but I am unable to implement it. I don't even know if it will work.
I highly doubt you can do this ... trapping key events that are not in your application is just malicious code.
Maybe you are interested in knowing if a call has been terminated?
If so: use the PhoneStateListener to detect state transitions from CALL_STATE_RINGING/CALL_STATE_OFFHOOK to CALL_STATE_IDLE
Related
I want to specifically know who ended the call. I have setup a broadcast receiver for
"android.intent.action.PHONE_STATE"
When I detect a transition from Off hook to idle, I know the call has ended. But how do I know who ended the call?
Thanks a ton!
I'm afraid there's presently no way to determine if the user pressed "end call" or if the other end (or ends, in a group call) terminated. The only workaround I can suggest is monitoring the other states to observe if the phone state ringing was encountered. In such a case, you could assume the user is making the phone call as opposed to receiving it.
Bear in mind that there are other problems related to PHONE_STATE, such as handling multiple calls simultaneously.
In retrospect, I'm not entirely sure what you mean with "who". As for other apps ending the call: there is no official API to end phone calls; only through reflection can an app invoke the TelephonyService's endCall() function. Here, too, it is not possible to determine if the call was terminated through user interaction or not.
I've been exploring Android's Telephony Manager a bit and fount out there is a way to listen to such events as ringing, off hook and idle. However, it's not enough for me...
When the call is actually initiated, I get an 'offhook' event, but I get nothing when the person I'm calling to, presses the 'Answer' button.
Is there a way to know EXACTLY when somebody actually pressed the Answer button when I call to him/her, in other words I want to know when somebody answers the call?
Any help\suggestions will be appreciated...
I don't think its possible. There's no such state/event at least I know of. So your best bet would be to stick with CALL_STATE_OFFHOOK.
I am designing an application in which I need to differentiate between a call rejected by the receiver (by pressing the dialing button) with the one not answered and is disconnected by the one who is dialing. is there anything that makes a differentiation since both of these come under the missed call category in Android?
You are lacking some details; please advise.
Are you referring to the Call Log provider android.provider.CallLog.Calls? There are only 3 call types defined. Can you provide the data of all the fields for such a Call Log entry?
The only other way (we know of) to tell is to watch the Phone State (via IntentReceiver) and track the transitions yourself. Most likely, a transition of Ringing to Idle would indicate the call was refused instead of answered, in which case it would transition Ringing to Offhook.
How are things now
This has been discussed in many questions but neither one offers a good solution. Things look simple, after having a BroadcastReceiver is really easy to intercept and block a call. The main issue that appears is the default Android incoming call screen. You know, the one with sliders for answer/end call. Because i have some rules to block the call, there is a small delay before the call gets hangup. In all this time, the Incoming call screen is active.
How I want things to be
I want the user to not get notified by this call blocking, as in my application I have a clear Log of all blocks done. So, the main thing remains: how do I prevent the Incoming call screen from starting?
It is not possible to completely block the calls but you can achieve this by listening the call and then disconnecting it. It's behaviour may be different in different devices. It may show negligible flicker over some device but that's the only solution.
Here is the approach how you can do that:
Android: Taking complete control of phone(kiosk mode), is it possible? How?
You can use BroadcastReceiver but for alomost blocking experience you need to use Service.
I'm writing an app using Android 2.1
At some point, I call setOnKeyListener
In particular, I write...
editfield=(EditText)findViewById(R.id.edittext);
editfield.setOnKeyListener(this);
This is in the main thread, in the onCreate callback.
At this point in the code, I would like the processing to stop and wait for the
keyboard input. If I let the code run on, the logic will break, soon enough.
I suppose I could put the machine in a wait loop until a keystroke invokes the onClick method. I could also create a wait loop at the point where the input from the user was required. But I don't feel comfortable with either of these solutions. (A related problem is this -- at a certain point in the code, the screen must be lit up. Must I check this before proceeding past that point?
Perhaps I'm not good with documentation, but I have not been able to find anything specific that answers these questions.
Can someone explain to me how to accomplish the timing I need and, more generaly, where I can find info on these questions?
Thanks in advance.
-looking in DC
The Android key system is event-based, it does not work like the old ask-and-wait mechanisms of C/C++ etc for obtaining user input.
If you blocked/waited - then what would happen if the user pressed the Home key (you can't catch that) or navigated to another app - your app would force close because it would still be waiting and your onPause etc would not execute.
My suggestion would be:
Put all the code that should occur after the click into some function
Place the listener at the end of onCreate, this way no more code will be executed after you set the listener
When you get a key-down, call your function. Thus the statements in your function will only execute after a key down
If however, this is for a game, then it is acceptable to have a thread dedicated to touch/key-events which sleeps for 50s or so to avoid event overload (but this must not be the main UI thread!)