My users are complaining that when they click the disconnect after playing a video, it does not stop the video.
Is that something the CastCompanionLibrary should be doing or do I need to trap the disconnect and do it myself?
I thought maybe by the time I get the disconnect event it is probably too late for me to be telling the app to stop the video playback.
CCL can do that if needed, but it is advised that you implement this in the receiver logic. I have explained the proper way of doing that in this post. Back to the first statement I made, you can use the following API to instruct the CCL to stop the running app on disconnect:
mVideoCastManager.setStopOnDisconnect(true)
You need to call that somewhere early from your application, say when you create the VideoCastManager singleton. But as I said earlier and is explained in the referenced post, that is not the proper way of doing that.
Related
I am trying to write an app that detects whenever any app on the device starts or stops playing music. My app is not a media player, it's more of a dashboard functionality, so I have no need of requesting audio focus, but I want to know when other apps do so I can update my status text accordingly.
Essentially, I believe that the function AudioManager.isMusicActive() will provide essentially exactly what I want to know, however since I am writing a service that will be always on I would like to avoid needing to poll that on a constant basis. I need the information in near real time, so it would essentially be a 1 second poll in perpetuity.
I'm looking for a way to detect when STREAM_MUSIC is being used by another app.
Some ways I have thought about doing it:
(1) Again, a perpetual poll using either Timer or Handler to constantly poll the isMusicActive() function. Not ideal from a battery or processor management perspective. I could use a flag variable in the UI Activity to control when the poll runs (it isn't really necessary when the UI isn't in the foreground, anyways), but I still think I'm using more processor/battery time than I'd need to.
(2) Listen for a broadcast of some kind, but none of the Android audio broadcasts seem to really fit the bill. (that I could find)
(3) I could, I suppose, request audio focus and just never play any audio and never give it up. Theoretically, since I am starting this in an always on service I believe that should allow my app to sit at the bottom of the LIFO audio focus stack and I would be notified via the AudioManager.OnAudioFocusChangeListener mechanism in basically the opposite way of its intended purpose (i.e. turn on my app when I lose audio focus and turn it off when I gain audio focus back). However, I'm not entirely sure how doing something like this would function in real-life usage. I feel like abusing the audio focus methodology for something like this could very easily result in negative user experiences in situations I haven't even thought of.
(4) Is there a way to use the AudioManager.OnAudioFocusChangeListener (or similar) without needing to request audio focus at all?
Are there any other ways I could go about doing this? Just a pointer in the right direction would be incredibly helpful!
I needed similar thing, so did a bit of research.
Unfortunately, there seems to be no other way to accomplish this except of requesting audio focus in your app.
Material for study:
Check Android source code in frameworks\base\media\java\android\media\ where you can find actual code for requestAudioFocus in MediaFocusControl class.
Other classes in this folder show how they send broadcast events for volume change, bluetooth on/off, etc, but no broadcast event at all related to audio enabled/disabled.
Another information on topic:
http://developer.android.com/training/managing-audio/audio-focus.html
http://developer.android.com/training/managing-audio/audio-output.html
Other than that, there doesn't seem to be any documented way to know when audio hardware starts/stops to play.
I trust that requesting audio focus without actually playing audio should not consume any battery. Only one ugly side effect is that this stops currently played audio.
I have developed Twilio SDK in my Android application. For outgoing and incoming it is worked well. But when i try to set the timer for call duration, i am unable to get the notification from the other device. Is there any method to find out the other device(Which was notified after picking the call)?
Please help me on this.
Thanks,
I'm not sure if you still need help with this or not, or I get exactly your issue.
What I'm doing is keeping the timestamp of when the call was started (incoming/outgoing) in any of the clients. Then in my activity/fragment, since I have my own callbacks for the Twilio events, as soon as I know there's a call going on, I use Chronometer which is like a TextView that automatically sets things as soon as you set a base time and start it.
get timestamp of when that call started
Chronometer.setBase(timestamp);
Chonometer.start();
So it shows the duration. Remember to have your own Twilio manager class to hold that value for you so if you leave your activity and come back, the duration will be displayed correctly.
Good luck
I want to specifically know who ended the call. I have setup a broadcast receiver for
"android.intent.action.PHONE_STATE"
When I detect a transition from Off hook to idle, I know the call has ended. But how do I know who ended the call?
Thanks a ton!
I'm afraid there's presently no way to determine if the user pressed "end call" or if the other end (or ends, in a group call) terminated. The only workaround I can suggest is monitoring the other states to observe if the phone state ringing was encountered. In such a case, you could assume the user is making the phone call as opposed to receiving it.
Bear in mind that there are other problems related to PHONE_STATE, such as handling multiple calls simultaneously.
In retrospect, I'm not entirely sure what you mean with "who". As for other apps ending the call: there is no official API to end phone calls; only through reflection can an app invoke the TelephonyService's endCall() function. Here, too, it is not possible to determine if the call was terminated through user interaction or not.
I've seen similar question posted, but with no answers.
My question is, after the intent to make a new phone call is initiated, is there anyway to keep the phone call active while accessing sound playbacks within a custom application?
If not, is it possible to modify the phone call activity, so the accessible sounds are in the same interface as the current phonecall?
You can keep the call active while playing audio in another application, but the caller won't be able to hear it. It would work like navigation directions while you are on a phone call, you hear them, but not the person on the phone.
You cannot modify the call activity to inject audio into the audio stream of the call, its an Android security measure as far as I know.
For various reasons, I need to use the raw SpeechRecognizer API instead of the easier RecognizerIntent (RECOGNIZE_SPEECH) activity.
That means, among other things, that I need to handle RecognitionListener.onError() myself.
In response to some of the errors, I simply want to re-start listening. This looks straightforward but when I just call SpeechRecognizer.startListening() upon error, this sometimes seems to trigger two different errors:
ERROR/ServerConnectorImpl(619): Previous session not destroyed
and
"concurrent startListening received - ignoring this call"
Which hints that I should have done some cleanup before attempting to call SpeechRecognizer.startListening() again.
If this is true, it means that upon a RecognitionListener error, listening is not automatically stopped and/or canceled.
It is also possible that some errors do stop/cancel listening, while others don't. There are really only 9 SpeechRecognizer errors:
ERROR_NETWORK_TIMEOUT
ERROR_NETWORK
ERROR_AUDIO
ERROR_SERVER
ERROR_CLIENT
ERROR_SPEECH_TIMEOUT
ERROR_NO_MATCH
ERROR_RECOGNIZER_BUSY
ERROR_INSUFFICIENT_PERMISSIONS
Since the documentation isn't very detailed about which error cancels listening and which doesn't, do you happen to know, based on your experience, which errors require doing cleanup (and to which extent) before attempting SpeechRecognizer.startListening() again?
No, cancel is not called when onError is invoked. You can look at the source here.
you can destroy current session by destroy(). And you can restart it again
Actually Femi, some of the error conditions DO stop the transcription service from listening (SpeechRecognizer.ERROR_SPEECH_TIMEOUT for example). It is not necessary to call destroy, just startlistening again.