Answering incomming calls and ending calls using the headset button

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by michael....@gmail.com on 18 Jul 2010 at 9:24

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 18 Jul 2010 at 9:48

[GoogleCodeExporter]

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

Original comment by michael....@gmail.com on 18 Jul 2010 at 9:53

[GoogleCodeExporter]

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-androi
d.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.

Original comment by r3gis...@gmail.com on 18 Jul 2010 at 10:01

[GoogleCodeExporter]

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.

Original comment by michael....@gmail.com on 26 Jul 2010 at 9:55

[GoogleCodeExporter]

This unfortunately no longer works after revision r174

Original comment by michael....@gmail.com on 20 Aug 2010 at 10:24

[GoogleCodeExporter]

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

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

Original comment by r3gis...@gmail.com on 20 Aug 2010 at 10:34

[GoogleCodeExporter]

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.

Original comment by michael....@gmail.com on 20 Aug 2010 at 10:45

[GoogleCodeExporter]

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).

Original comment by r3gis...@gmail.com on 20 Aug 2010 at 11:34

[GoogleCodeExporter]

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.

Original comment by michael....@gmail.com on 20 Aug 2010 at 1:25

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 20 Aug 2010 at 1:51

Attachments:

• CSipSimple_0.00-12-19.apk

[GoogleCodeExporter]

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.

Original comment by michael....@gmail.com on 20 Aug 2010 at 2:12

[GoogleCodeExporter]

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

Original comment by michael....@gmail.com on 2 Sep 2010 at 10:40

[GoogleCodeExporter]

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.

Original comment by r3gis...@gmail.com on 2 Sep 2010 at 4:41

[GoogleCodeExporter]

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...)

Original comment by r3gis...@gmail.com on 2 Sep 2010 at 7:52

[GoogleCodeExporter]

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 :-/

Original comment by michael....@gmail.com on 2 Sep 2010 at 8:04

[GoogleCodeExporter]

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/jav
a/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.

Original comment by r3gis...@gmail.com on 2 Sep 2010 at 10:28

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 6 Sep 2010 at 8:32

[GoogleCodeExporter]

Original comment by r3gis...@gmail.com on 19 Sep 2010 at 6:08

• Changed state: NextRelease

[GoogleCodeExporter]

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. 

Original comment by coolna...@gmail.com on 16 Dec 2010 at 3:51