#96 Answering incomming calls and ending calls using the headset button

[Anonymous]

Originally created by: michael....@gmail.com
Originally owned by: michael....@gmail.com

It is not possible to answer incomming calls by pressing the button on a connected wired headset. The application needs to catch the button press event and if a call is incomming the answer it. If a call is ongoing it should be hangedup.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Great !
The issue 51 is also related to bluetooth, feel free to reassign it if you want ;)

[Anonymous]

Originally posted by: michael....@gmail.com

Going to see if I can get the wired headset working as expected first. Bluetooth seems to be handled a little differently.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Ok,

If you use APIs that are not available in android 1.5 or 1.6, try to create a wrapper to avoid crashes on 1.5/1.6 devices.

Here is a very interesting article on that point :
http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html
For now I've only used the reflection method, but wrapping class can be a better way for the current Bluetooth case.

If you want, I can take this point later once you'll get things working on api level 5 and more.

[Anonymous]

Originally posted by: michael....@gmail.com

Have added functionality for this which finally seems to work as expected. Supporting both both 2.2 and older devices was a bit of a pain though and forced me to do it more complicated then I had originally expected. Interacting with other applications such as the media player seems very unpredictable even if you follow the recommendations.

I noticed that the standard phonecall handler just mutes the microphone when the headset button is pressed during a call instead of hanging up. This is not really the behaviour that I would like, however since it is how the standard phone app does it I think it should be the default behaviour. So I will add a setting before I check in to choose if csipsimple should hangup or mute on headset button presses during calls.

[Anonymous]

Originally posted by: michael....@gmail.com

This unfortunately no longer works after revision [r174]

[Anonymous]

Originally posted by: r3gis...@gmail.com

Ok probably my fault. I'll have a closer look.

You are using the headset shipped with the nexus one or another one?

[Anonymous]

Originally posted by: michael....@gmail.com

I have a few different ones, but also the default Nexus one. In my experience if it works with the default one then it works with the others I have as well.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Don't know if it's is possible but seems that the priority of the music app has changed on nexus one for media_button intent...

So priority has simply to be changed and works for me.
with intentFilter.setPriority(IntentFilter.SYSTEM_HIGH_PRIORITY +1 ); instead of high priority intentFilter.setPriority(IntentFilter.SYSTEM_HIGH_PRIORITY - 1 ); is enough to fix the problem on my device.
You'll probably say that setPriority should not be higher than system_high_priority... but if we consider that we are replacing a native behavior... it make sense. I think that SYSTEM_HIGH_PRIORITY is just a value in the documentation to advise developer to not override native behaviors.
Btw, the new API could be a solution too, but it's really simplier this way.

Micheal can you test on your device replacing the priority in UAStateReceiver from -1 to +1 (or you can try with + 100 if it doesn't work with +1 ).
At least on my device, it was not working anymore with -1 (but when I push the commit I'm pretty sure that it was working). With +1 it works fine now.

Else if it doesnt work I will make a switch that use new api and reuse the same intent receiver if API >= 8 (as it is done in the official music app).

[Anonymous]

Originally posted by: michael....@gmail.com

Saw something similar when I was implementing this before which is why I ended up implementing both solutions. I do not think it is the media player that changes the priority. Maybe the system service that distributes the buttton presses in the "new" way has a priority of SYSTEM_HIGH_PRIORITY...

Either way if you handle the event using the onKeyPressed it will always work when the ui is active regardless of if other applications manage to hijack the broadcast.

I am on my last day of vacation :-) so I do not have the possibiity to build anything right now. You would have to build an apk for me to try.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Attached to this post.
Works on my nexus one with the default headset.

[Anonymous]

Originally posted by: michael....@gmail.com

Appears to work for me too.

Noticed another strange behaviour though... When I answer incomming calls I get the "Hung Up" dialog and then the ui disappears but the phone keeps ringing for a good while.

[Anonymous]

Originally posted by: michael....@gmail.com

Using the latest dev version (12-26) and it is no longer working to hangup a call with the headset button :-/

[Anonymous]

Originally posted by: r3gis...@gmail.com

Oh... I'll check that again!
I'm wondering if I should not put a really high value for the intent priority instead of relying of the "max value".

I'll try, thanks for the report.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Strange, I've just tried to reproduce on my N1 with official headset, it's still working properly. Any new app you installed that use the "new" api that prevent others apps from receiving headset actions?
Maybe you could try building the app with an higher priority when registering for headset actions. (Let me know if you get any success changing the priority... since this value is a little bit empiric...)

[Anonymous]

Originally posted by: michael....@gmail.com

I do not think I have installed anything new. Maybe some update to some app. I have a few media players installed but that for testing when I was implementing this but I have not updated them. I think even the standard media player uses the "new" api in 2.2.

This is exactly the same problems I was having and the reason I implemented both the "new" and the "old" way because on my Nexus One with Froyo the new API was the only way to get the headset button to work consistently in all situations :-/

[Anonymous]

Originally posted by: r3gis...@gmail.com

Indeed, but regarding the android source code, new and old api are both using the same intent. That's just two way to access it.

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=media/java/android/media/AudioService.java#l307

However, I'm not really confident on how priorities higher than the max priority are handled. Good side using old api is that it's absolutely not intrusive on other applications. If button should be handled by csispimple we abort the intent, else we just let other apps (or the registeredMediaButton) handle it.
Well, I should probably reuse the new api when possible using reflection to ensure it works with 1.5 devices too.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Ok, it has been refactored and put into the same wrapper than the one that manage audio focus (and music pause/start). So it now use 2.2 api if available and else relies on the old api (with intent priority... I've increased it again).
Should be safe to backward compatibility and in 2.2 mode will catch media button events only if necessary. Let me know if it's more stable for you now (tested on my N1 2.2 with official headset and works). Looks like your previous implementation now (excepted the fact it's splited in another unique broadcast receiver that is registered using api level 3 or 8)

=> version -12-29

[Anonymous]

Originally posted by: r3gis...@gmail.com

(No comment was entered for this change.)

Status: NextRelease

[Anonymous]

Originally posted by: coolna...@gmail.com

Should answering and closing call work with current version (00-16)?

On my phone it's not working.

Also, when having incoming call the screen lock won't go off as when having regular
mobile incoming call, thus I have to first remove the screen lock and then slide to answer.