I am writing an Android app that reads external hardware through the microphone input. My problem is that sometimes the phone thinks that the signals that are coming through the mic are "play" button presses and starts playing music. (the play button shorts microphone to ground, and some of the signals I'm reading are close enough to that)
I have seen apps that block the play button from a headset. I wonder how I can add this functionality to my own app.
Just a guess: Set up a broadcast receiver for the ACTION_MEDIA_BUTTON intent and handle it so it doesn't get passed on the music app.
Perhaps you should AC couple your input signal with a series capacitor? This will give a limit on the low frequency response, but you probably shouldn't depend on that anyway.
Related
I have an Accessibility service that processes the surrounding sound with a microphone, and a process runs every time the user says Hey.
The problem is that when I listen to the microphone in the background service, no other software can use the microphone.
One way is to listen to access events whenever an event is received from the software with a premium microphone and disable my application process for a short time. But this is a bit non-standard and does not work to some extent ... Is there a way to access the microphone in such a way that any other program can access the microphone at any time and my program will automatically receive sound ?? Something like channels in audio playback !!
Or the way I can hear that a program needs a microphone !!
Thanks ❤️
I'm writing an Android music player, and is stuck on audio focus issue.
It seems like audio focus mainly affects media button receiving, but after reading the document I have no idea about when to gain and give up focus.
My music app will run in background, and need to detect play/pause button every time. That is, even when my app is not running, a user should be able to press headset's play button and start music.
It seems I should never give up audio focus, so why should I implement it?
Does anyone know practically how audio focus should be used? Thank you!
It seems like audio focus mainly affects media button receiving, but
after reading the document I have no idea about when to gain and give
up focus.
They both are separate functionalities, and thus have separate listeners. You may have audio focus taken away from you but you may still choose to respond to play pause hardware keys
That is, even when my app is not running, a user should be able to
press headset's play button and start music.
I am assuming that you meant by the above line is that you are still playing music but not showing an activity. To keep listening to hardware button press, dont unregister your media button receiver(dont call audioManager.unregisterMediaButtonEventReceiver(receiver) yet).
It seems I should never give up audio focus, so why should I implement
it?
you dont give up the focus , it gets taken from you. To handle that gracefully you have AudioFocus listener. For ex, consider an incoming phone call. Would you still like to continue playing your music?
Right now my application lets the user start recording audio and puts an ongoing notification that can pause/restart recording on press using android.media.AudioRecord. All was fine and dandy until I realized that this blocks any other App from using an AudioRecorder (ie google voice search).
Is there a way I can set up a broadcast reciever to detect a call for an AudioRecorder from another app and pause my recording. Alternatively, is there another way to record audio that wont interfere with other Apps that use audio?
Cheers!
I have been looking into this very question for a while now. It seems that there is no clean way of achieving this as there is no broadcast that alerts when another app would like access to the mic.
The way that we have solved it (albeit not cleanly) is we poll what app is in the foreground and get its permissions; if that app has permission to use the mic, we terminate recording until there isn't an app in the foreground with the mic permission.
Although polling is a solution, I would be very interested if anyone has better!
All,
I have searched for an answer to this, but I'm not getting anything exact... It's my first time writing an Android app, so please be gentle :)
I'm pretty bummed about the minimal headset support in Android - unlike e.g. iPhone, it only natively seems to support a single button, so no volume control on headset compatibility. Additionally, if I'm listening to music and a call comes in, the OS pauses the music automatically, but the headset button still functions ONLY as a media button - I can't use it to answer/end the call. If I answer the call via the screen and press the headset button, the music starts again, but the call continues...
I'd like to create a 'middleman' app that can pick up that the headset button has been pressed (via Keyevent.KEYCODE_HEADSETHOOK) and can then determine whether to perform the default ACTION_MEDIA_BUTTON action (toggle play/pause in my chosen media player) or, if there is an incoming call, pause the music and answer the phone (and then, when pressed again, end the call and restart the media player). Perhaps even check for ACTION_MULTIPLE on the headset button to assign different options (ACTION_MEDIA_NEXT, ACTION_MEDIA_PREVIOUS etc.). Perhaps also be able to determine whether different buttons on the headset have been pressed (if the headset is e.g. a fancy iPhone headset) and 'translate' those button presses into the appropriate ACTION_MEDIA_*). This might not be possible if the OS can't tell the difference between different buttons, obviously.
Obviously such an app would have to receive the intent with a high enough priority that it would be able to abort the broadcast before the current media player gets it.
I've been tinkering with creating assorted BroadcastReceiver classes and intent filters etc., but part of the problem is that the bult-in Android emulator that comes with Eclipse doesn't seem to have the ability to simulate a user plugging in the headset and/or subsequently clicking the headset button. Therefore, every time I get somethign that looks promising, I have to put it onto my actual phone and try it out - time-consuming and a hassle.
3 questions then:
Am I missing somethign obvious - is this a real problem and if so, has it already been solved?
If it IS a problem, is it possible to write such a middleman app?
Are there any other Android emulators that can check for headset-related activities?
Thanks,
Rory
i´ve already written exactly this kind of app. Its called like the topic of this thead: Headset Button Controller ;-)
http://www.androidpit.com/en/android/market/apps/app/com.kober.headset/Headset-Button-Controller
Cheers Christoph
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.