I have integrated the latest cast SDK within my Android application. It does play media correctly and I'm able to control the playback via on-screen controls as well as via the status bar notification and lock-screen.
I have received, though, reports from some users saying that after a while listening to the media via cast, when their devices went to sleep/got locked, they were not in sync with the receiver anymore as well as losing the possibility of controlling the playback.
I was not able to consistently reproduce the issue (since forcefully locking the device keeps the connection for a while), but I could see it happening a number of times and was able to catch logs for one of them.
At first, I was suspecting that the receiver's messages were not arriving to the sender (android app), but the Google Home application works flawlessly and updates the metadata and playback controls correctly. So, the pain point must be in my application.
I did notice that, while in that "inconsistent state", I am still able to read logs after a track finishes (so, change of state) as follows:
02-05 00:02:08.958 16642-27384/? W/CastDeviceController: [controller-0335 API] Ignoring message. Namespace 'urn:x-cast:com.google.cast.media' has not been registered.
Do I need to register that protocol within my application? (I do use a custom protocol to send messages - and if I'm not mistaken, the "unregistered protocol" is the default one - shouldn't it be automatically registered?). If so, how can I perform that registration?
Any help will be appreciated.
Related
I've implemented VoIP calling in a native Android application, and we've discovered a bug that I'm stuck on. I'm using Twilio for our VoIP calls if that helps at all.
If I place an outgoing VoIP call from our app, after the call ends if I put the app in the background and receive a notification, the volume of the notification is about half what it was before I placed the call. It's also not just notifications from my app, but other apps are affected as well. If I swipe my app away from the app history so it is no longer running in the background, then notifications go back to to playing at their correct volume.
This does not happen when I receive an incoming call, even though I've verified that the same code tears down the call Connection whether it's incoming or outgoing.
I've verified that when the notification is coming in, the device's notification volume is still turned all the way up using AudioManager's getStreamVolume(AudioManager.STREAM_NOTIFICATION) API.
Since all apps appear to be affected, not just my own I'm thinking I can safely assume it's not the code that's playing the notification sound that's the problem. I was thinking maybe something related to the VoIP call wasn't being released properly, and the OS itself is playing the tones at a lower volume because it still thinks we're in a call, but I can't find any evidence of that.
I've confirmed that my Connection object for the call is calling onDisconnect(), and destroy().
My ConnectionService is also being destroyed.
The call state at the time of the notification is not CALL_STATE_OFFHOOK according to the TelephonyManager.
Is there anything else you can think of that would cause notifications to play at a reduced volume?
We also experienced this same issue in our VOIP application, although in our case we're using webrtc directly and not Twilio Video -- so I don't know if this exactly applies to your case but maybe can help you find some clues.
In our case, we discovered we were not calling close() on all of the WebRTCPeer objects. That meant after the call ended, an AudioTrack was still active which affected the audio routing... resulting in the very quiet ring/notification sounds.
I would guess the equivalent with the Twilio Video SDK is to make sure that you unpublish and release all audio tracks (and video and data tracks) and then disconnect the Room object.
https://twilio.github.io/twilio-video-android/docs/latest/com/twilio/video/LocalParticipant.html#unpublishTrack-
https://twilio.github.io/twilio-video-android/docs/latest/com/twilio/video/LocalAudioTrack.html#release--
https://twilio.github.io/twilio-video-android/docs/latest/com/twilio/video/Room.html#disconnect--
We found some good clues examining the output of adb shell dumpsys audio -- in the bad state, we could see in the "Stream Volumes" section that the device for the ring/alarm/notification streams was stuck on "earpiece" rather than "speaker", and that there was an extra AudioTrack in the "Players" section.
Maybe this gives you some ideas to try... good luck!
When de app is in the background for a while (usually about half an hour) the connection is broken. The logs do not show anything, even while I have created a partial wake lock and put the app on the Doze whitelist.
This causes the media flow to be stopped, which is not something we want to have. Since the called side then receives a hangup message, but the app does not, the media just stops flowing.
While trying to debug this, I also note that logcat is disconnected after a while (might be a android studio on mac issue. Have had more problem with this). So debugging this is very difficult.
Here is the thing, I am not used to the latest android yet and the new system is giving me some confusions. Usually, for the older androids, if I close all background apps, I won't get new notifications from them. But after switching to a new phone with the latest android, I realized that even if I do close all background apps, I still keep getting notifications from them. So, how are the apps still pushing notifications if I already close them from background?
(Say google maps for example, I am 100% sure I killed it in background but now it keeps notifies me about my live traffic status on my notification bar.)
So Here's the answer-
Yes, they are. Whenever the Internet is turned on or you get a message, listener of that app wakes up and check for any notification and if there is something new, it shows you the notification.
These apps keep running in the background if not put in sleep mode by your phone and use the resources.
Like you don't want to get notified by WhatsApp for a new message but the moment you change the network, unlock your phone again or turn the data on, an event listener will wake up and notify you of new messages.
Also, wake timers are used to notify you after some fixed time like after every 5 minutes.
This is the thing I hate the most.
Not promoting but here's the app - search play store for Shutapp - Real battery saver (Blocked from Play store a while ago and doesn't work anymore for "obvious" reasons). It will turn off all the background apps and you'll be amazed to see a long list on first use.
This will remove all the apps from background until you open them again. I use this app most of the time and it really works great.
Try this out.
I have an Android app using the CastCompanionLibrary v2.9.1, modified to use play-services-cast:10.0.1 (just a simple change to the gradle dependencies).
Short version: The app is attempting to automatically connect to the ChromeCast device, without user interaction.
Long version:
Since updating the CCL library to use play services 10.0.1, I've had several users mention that the app is automatically connecting/casting to ChromeCast without user interaction.
Some users have said they're not using the app, then they connect to WiFi, and the app automatically attempts to cast. Others have said they are using the app, they don't press the ChromeCast button, and the app begins casting.
--
I'm having trouble figuring out where to look for potential changes to the ChromeCast APIs which might explain what's going on. I'm also not sure whether this issue is only occurring for my app, or for many other ChromeCast enabled apps. Lastly, I'm not able to reproduce this issue on my own ChromeCast device.
Any help would be appreciated.
I had not seen or heard this before, so here are some pointers for you to do further investigation to see what can be the cause. CCL has a (sticky) service called ReconnectionService that is responsible to perform reconnection attempts when you lose wifi and later gain it back. The wifi scenario you had mentioned resembles this so I would suggest to start from there. In order to only reconnect when it makes sense, it gets the time length of the content that is playing and only makes such attempts for that period of time; i.e. if you start playing a content that is for 1 hr and then you leave your phone on the table and pick it up after 2 hrs, it notices that the last movie before it fell sleep was for 1 hr so it won't make any attempt to reconnect (see handleTermination() in that same class). For live-stream that doesn't have a clear content duration, CCL uses a default of 2hrs but allows apps to modify that by calling VideoCastManager.setLiveStreamDuration(duration_in_seconds) method. Finally, the whole reconnection relies on a few factors: it saves the route-id of the last connection, along with the session ID. So if needed, you can clear any of these and then it won't try to reconnect for that particular session (in case you want to keep reconnection for some and disable on some other). Hope these help to troubleshoot the issue.
So it turns out there's a bug in Android Support Library 25.1.0 which was causing this issue.
https://code.google.com/p/google-cast-sdk/issues/detail?id=1105
Which is now marked as 'fixed internally'.
Also related:
https://code.google.com/p/android/issues/detail?id=232326
The "Google Play Services" library contains an integrated fallback system in case of lost packets?
Here is the problem. I have a app that works like this:
The player A sends a reliable message to the player B
The player A can not send another message as long as the player B has not returned a callback via a reliable message.
If the callback takes too long or is negative, the game is disconnected.
Thereby I ensure that the game always remains synchronized.
The problem is that sometimes, when the connection is poor, the player B's game get suddenly a few steps back (usually 3 to 5).
The interesting thing is that this application has no methods to get back this way, and that it remains connected after this, although it's out of sync.
I have found nothing in the official documentation.
Did one of you already experienced this issue?