Answering incomming calls and ending calls using the headset button
Brought to you by:
krunalhire
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
Great !
The issue 51 is also related to bluetooth, feel free to reassign it if you want ;)
Related
Tickets: #51
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: michael....@gmail.com
This unfortunately no longer works after revision [r174]
Related
Commit: [r174]
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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?
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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).
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
Attached to this post.
Works on my nexus one with the default headset.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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 :-/
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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...)
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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 :-/
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: r3gis...@gmail.com
(No comment was entered for this change.)
Status: NextRelease
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
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.