I previously developed an android sender app with the preview SDK and found that when a Chromecast was turned on or off, the app very quickly discovered this and changed the state of the media route button.
However with the new SDK, if a Chromecast is unplugged while the app isn't connected to it, MediaRouter.Callback.onRouteUnselected() is never called and the Cast icon remains visible. In some cases even if the app is closed and opened again, onRouteAdded is called on startup with the details of the previously connected Chromecast, even though it's not plugged in anymore and hence not on the network, which suggests that there's some kind of cache somewhere.
I'm noticing this both with my own app (which uses the companion library) and the example CastVideos-android app on github. This sets up the callback like so:
mMediaRouter = MediaRouter.getInstance(context);
mMediaRouteSelector = new MediaRouteSelector.Builder().addControlCategory(
CastMediaControlIntent.categoryForCast(mApplicationId)).build();
mMediaRouterCallback = new CastMediaRouterCallback(this, context);
mMediaRouter.addCallback(mMediaRouteSelector, mMediaRouterCallback,
MediaRouter.CALLBACK_FLAG_PERFORM_ACTIVE_SCAN);
This results in a pretty rough user experience - is there any way I can improve it? Perhaps some flag that I can pass that'll perform an even more active scan than CALLBACK_FLAG_PERFORM_ACTIVE_SCAN, hence detecting Chromecasts that are no longer on the network? Or perhaps some method that I can hit at intervals to scan again and make sure the chromecast is still there? I've had a look through the API but I can't see anything.
EDIT: Worse still, I've also noticed that if a Chromecast is unplugged then you attempt to cast to it, it will disconnect (good) but won't detect the Chromecast when it's plugged back in. This is true even if you get out of the app and start it up again.
The behavior you have outlined is caused by a bug in the SDK that is going to be addressed in the next release of the Google Play services.
Related
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.
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?
Android M has a new feature called App Standby where an app is put into an idle state when it's not being utilized (see docs) and, among other things, its network access is disabled.
I can't seem to figure out a way to determine when the app goes into and out of this state (via a broadcast intent or something of the like) and I really need to as my app relies on having network periodically to check the status of a server.
Can someone help me figure out how to determine when my app goes into and out of idle state?
I've been digging through the M preview 2 source and down through the calls of $ adb shell am set-inactive it appears that there's a AppIdleStateChangeListener but it appears to only be used internally to Android and isn't exposed to us lowly developers who want to know when our apps can use the internet :-(
So far, it appears that when ACTION_POWER_CONNECTED is broadcast, all apps come out of standby...this is a potential workaround if Google doesn't expose something for us before release.
I have a Bike computer app that logs data while the user is riding. I have had a user report an issue I had not considered. He was out for a long ride (100+ miles) but while out and logging data the app got updated via Google plays auto-update. This unfortunately killed off the app mid recording and the user lost data till they spotted what had happened and restarted the app.
Ideally I would like to be able to programmatic stop the auto-update happening while the app is data logging. All my research indicates that this is not possible possible but I may of missed something so dose anyone know of a way of doing this?
Given no solution the best I can do is advice the users to enable the update only over wifi option in the Play app which in this instance would of helped. Unfortunately one of the key points about my app is that it will log indoor sessions using ANT+ sensors so I have a good number of people using it with wifi active.
Edit
I managed to do the experiment to see what happens myself last night. I had an app going in the background data logging then pushed a new version to Google Play. Unfortunatly it was not picked up totaly automaticaly when I had to leave 10 hours latter but I opened up the play store app and it found the update it did not start updating automaticaly but I forced it. The act of downloading and installing the new version killed off what was in progress. It was already dead before I used the notification to go to the new version.
As you say yourself, you can't do that what you are asking for. You could hack your way around it by changing the permissions each time you update. The users will then be prompted about it in the regular way.
I'm not sure about the "life-cycle" for automatic updated apps that are running. But I read somewhere that is wasn't the re-install but the reopen of the app that crashed it. If that is the case you could set a flag indicating that the user is currently logging and then on restart just resume the logging. But again we need to know more about the inner workings of activities/apps which are running and get an automatic update (actually didn't think it could happen).
Edit
Based on your findings I'd say you have to handle the app is shut down in onDestroy etc. or/and make sure you save everything persistently. Then you might need to have 2 apps where 1 listens to the other being re installed and when that happens it starts it up again (there is an interesting discussion here). If you are targeting api >= 12 then the broadcast action ACTION_MY_PACKAGE_REPLACED might also have interest.