I am trying to develop an android application which requires detection of if phone is muted during an incoming call is active(ringing). Some phones have a mute button which instantly mute the sound of the call but does not stop the call (phone is ringing in silent).
Before the call, phone is not muted, but when the call begins, user decides to mute the phone with this button. I want to determine if this situation is happened or not.
I tried to read RINGER_MODE_CHANGED_ACTION but it seems that this button does not change the RINGER_MODE(Maybe I am wrong).
So how can I do that?
Related
I wrote an app which starts record audio in response to holding volume up button on phone or headphone, I'm doing it inside dispatchKeyEvent method and it's fine
Problem is, I want to do it when the phone is locked in my pocket, I want to just hold my headphone volume button and start recording, How can I do that in Android? How can you do anything in response to user actions when the phone is locked? For example, how can a music player respond to the user pressing play/pause button on headphone? I know that it is possible, but I don't know how...
I'm doing a cross platform app in visual studio, I want to know how to play sound in ear speaker, like mobile ringing sound while we make a call, can any one help me for this?
UPDATE
Actually I was trying to do SIP calling. I have used Android.Net.Sip. I can able to call to SIP Numbers but before pick the call from end user the ring sound cant be ringing in my mobile.
Its having this functions but I cant able hear ring sound
//Called when a RINGING response is received for the INVITE request sent.
public override void OnRingingBack(SipAudioCall call)
{
base.OnRingingBack(call);
}
for this I was tried to play ring sound using media player, but this will use loud speaker, for this I want to play ring sound in ear speaker or can we can able play ring sound using above functions. can any one help me for this?
No need to restart your phone. Just close the running apps and try the audio. It'll be normal, through your main speaker. I've observed one thing. While the music is coming through ear speaker just make a call, that automatically pauses the playing audio, and in the call put on the loud speaker and now go to the music player (don't disconnect the call, let it go in speaker mode) and turn on the music, now the audio will get out through main speaker in normal way. Again putting off the speaker mode of the current going call throw back the audio to ear speaker. After disconnecting that call also the audio will play through ear speaker only. I don't know the reason behind this. This is just my observation. Finally I would like to conclude that, no need to restart your phone. Just close the running apps (all) and now try the audio. It'll be fine.
Is it possible to mute the phone while my app is active? Or to even disable the phone call screen?
My use case is following:
I have a music player in my app and it's a fitness app, so the user does eventually not want to be disturbed. So I want to allow him to activate a "do not disturb" mode, which disables incoming call notifications, at least the sound.
What I need is following:
Bluetooth must work, because of the headphones, so plane mode would not even be a manual workaround
Can this somehow be achieved?
I want to create application in android in which i can listen music to the other side person...for that i have written code..in that code ....when phone state goes to OFFHOOK mode music start automatic....but there is problem with that.....music start even though phone has not been recived....means when phone is dialing....at the same time music start....i want music should start when the other side of person receive call.......
thanks.....
Haven't tested this (not on my workstation), but I think you could check for the phone state CALL_STATE_RINGING and start the music when the state changes from this to CALL_STATE_OFFHOOK, this should mean that the call has been answered.
I am trying to figure out what is the correct (new) approach for handling the Intent.ACTION_MEDIA_BUTTON in Froyo. In pre 2.2 days we had to register a BroadcastReceiver (either permanently or at run-time) and the Media Button events would arrive, as long as no other application intercepts them and aborts the broadcast.
Froyo seems to still somewhat support that model (at least for the wired headset), but it also introduces the registerMediaButtonEventReceiver, and unregisterMediaButtonEventReceiver methods that seem to control the "transport focus" between applications.
During my experiments, using registerMediaButtonEventReceiver does cause both the bluetooth and the wired headset button presses to be routed to the application's broadcast receiver (the app gets the "transport focus"), but it looks like any change in the audio routing (for example unplugging the headset) shits the focus back to the default media player.
What is the logic behind the implementation in Android 2.2? What is correct way to handle transport controls? Do we have to detect the change in the audio routing and try to re-gain the focus?
This is an issue that any 3rd party media player on the Android platform has to deal with, so I hope that somebody (probably a Google Engineer) can provide some guidelines that we can all follow. Having a standard approach may make headset button controls a bit more predictable for the end users.
Stefan
Google has a detailed blog post on implementing the newer 2.2 AudioManager media button event receiver while maintaining backwards compatibility with older devices.
http://android-developers.blogspot.com/2010/06/allowing-applications-to-play-nicer.html
After some experiments, I was able to get a working solution with the new transport and audio focus infrastructure in Android 2.2.
What I end up doing is requesting both the Audio Focus (using AudioManager.requestAudioFocus) and the Trasport Focus (using AudioManagter.registerMediaButtonEventReceiver) every time my application starts playback.
requestAudioFocus takes a callback that is called when the audio focus is taken away from you (for example the internal player starts a playback). In my case I just pause the playback in my application if the focus is taken permanently. Same callback also now tells you that the focus is taken only temporary (for example the Nav system is talking) so you can "duck" your playback - lower the volume or pause and resume after it is done talking.
The only issue remaining is that the built in Music Player takes the transport focus every time you connect a Bluetooth headset. This has the effect where the first press of the Play button on the headset after connecting it, always starts the playback in the default Music Player.
There is probably a way to detect the headset connection and "hijack" the transport focus. In my case, I decided to not "fight" the default player, and get the transport focus back when the user manually starts the playback in my application.
If somebody has more insight or knows of a better way of handling the transport/audio focus, please share it.
I also have this same issue with the media button registration.
Periodically the Android returns the media button registration to the default music player. I have not been able to figure out why. This can happen while may application is actively playing as well as while my application playback is paused.
After a number of users complained that their Bluetooth pause and play control buttons would periodically stop working to control my application, I implemented code that re-registers my application by calling registerMediaButtonEventReceiver every 2 seconds. This allows me to get the button registration back and for the most part avoids the time window where where the user presses a Bluetooth media button and the default media player ends up responding.
My application is holding the audio focus during this entire time period, but still loses the Bluetooth button events periodically while it has audio focus. My application always unregisters the media button event receiver if it is called with a notification that it is losing the audio focus, and then registers again if it is later called when a temporary audio focus loss returns the audio focus.
The work around to keep the 2 second timer running and re-registering has been working, but I would like to get rid of this 2 second timer if someone has found a work around for the media button registration periodically switching back to the default media player.