A user make a new task A and set the alarm, then he make another new task B in the same time and also set the alarm.
When the alarm for task A come up,the user doesn't dismiss the alarm on time,the alarm for task B just come after it.Well,now it's duet.
I want some help for judge the statue if the phone is playing any music sounds or how to prevent the alarm to show duet.
My project must depend on API 7.
To get the statue of phone whether it is playing a sound file, you can refer this document.
Before your app starts playing any audio, it should hold the audio focus for the stream it will be using. This is done with a call to requestAudioFocus() which returns AUDIOFOCUS_REQUEST_GRANTED if your request is successful.
Related
I have a camera activity that can record video. I think that some of the code for setting up the video recording possibility also runs some code (under the hood) for preventing the recording to be disturbed if a phone call or an alarm goes off. (However I need to stop the recording when an alarm goes off.)
I would like to add some kind of "receiver" (or something similar) that can register if something like a call or an alarm goes off, and was wondering if anyone knows how to know when an alarm goes off during a video recording.
I'm having trouble determining if iOS and/or Android has the capability of starting audio playback from the background. The general order of operations would be...
User starts app
User chooses to hear audio when they arrive/depart a location
Region monitoring is used in the background to determine location changes
Region is entered/exited: if the app is configured to play certain audio for this region, load it from a URL and start playing it. If another track is already playing, queue the new one.
If music/other audio is already playing in the background, duck it until my queue has completed
I know that I'll need to enable background audio, but I'm not able to determine if I can initiate playback from the background.
In my application I want to get start time of music player when user started and end time when it stops.I don't want to start any music player in my app. I just want to track user activity in device. So i want my application to get any notification when user started the music .
Do I get any intent for music player started and it stopped.Or do I get any intent for when user opens music files.
Is there any other method other than intent to capture the start time and and time when user starts music player.
Well you can implement the interface 'AudioManager.OnAudioFocusChangeListener' in which there is a method 'onAudioFocusChange' which lets you know if audio focus has been changed, and it can also tell if focus was gained or lost.
See this link, it explains the Audio Focus in detail. An application must gain audio focus through a request, and you can implement the 'AudioManager.OnAudioFocusChangeListener' and if there is focus gain, you can detect if the media player is running, (because some other application such as you tube may gain focus to play its audio), see this to see how to detect which application or service is currently running. You can find if audio has started to play, and if it was the media player or not.
Hope this helps. It was interesting question and I have learned some new things while searching for the answer!
Actually i am creating an application which starts recording when user start speaking and
stop recording automatically when user stop speaking.
so is there any way to find if user is speaking or not?
is there any listener for Media Recorder for this?
No, AFAIK there are no listeners or intents that would notify your app that sound level has gone above some threshold (e.g. user started talking).
You could use AudioRecord class to record the microphone audio and then analyze it to see the volume. However this would require your app to run at that time.
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.