I have a video app (client a) that streams and receives audio via flash media server. It also does constant server side polling to maintain an engagement via an adobe air desktop app (client b) which does the same. The problem I'm having is that:
- 90% of the times when client b ends the engagement the app in client a force closes.
- 5% I have seen the app force close from when client a ends the engagement.
- works fine in gingerbread. Doesn't in honeycomb+
Debug doesn't throw anything, logcat throws an error that consumer closed the input...
I have isolated the problem to my flash media server class, however I am not doing anything different than any other connection class.
Has anyone ever experienced this issue? Like I said itworks fine in gingerbread...
Any pointers would be great.been banging my head against the wall for 2 weeks now and counting
Took a while to find the issue but in the end it was an issue in the fms server.
I was running a function at an interval to check for user timestamps among other things, however when the engagement was being finished by client b, the timestamp was stillt rying to run and disconnect a user, even though the connection was already closed.
Once I got that sorted the issue went away.
It is still weird how this issue wasnt affecting android 2.x devices...
This is probably not going to be very helpful to many people, however if you do see your app force closing, and one of the last messages your app receives is down to the fms, have a check for something your doing in the .asc file in your fms.
Unfortunately learnt this the hard way, spent 3 weeks looking at my code, thinking it was something it was doing or some kind of bug...
Glad I was wrong!
Related
I have one problem when I close my app under android, it's call the TmyMainForm.destroy, and this can take some time to free everything. The problem is that all dephi apps are with launchMode="singleTask", so still, the app is not fully closed, you can not launch it again. Now I feel that I can simply do nothing in the procedure TmyMainForm.destroy, even don't call inherited. This seam to work in the tests I did but I m afraid that I do not see some problems this can produce like for example crashing the app because one HTTP connection was working and thus producing report, etc..
question: is it acceptable to ignore TmyMainForm.destroy under android? else is there something like halt in android to stop/kill immediately the app ?
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
I used CrashLytics to make an application that I made send error reports whenever my users encounter them. The application is wonderful and works really great. I am able to get the reports on the dashboard almost immediately after the application crashed and it includes the line number and the exception that was encountered, it was like I was looking at the LogCat itself.
I noticed that it doesn't send the error report when the device is offline which is pretty understandable. I then turned the WiFi on, waited for ~3 minutes, refreshed my dashboard, and I was hoping that the error report would send automatically. However, I didn't get any new reports on my dashboard. I had to open the application again (while the device was online), wait for a minute or two, then I saw the new errors.
I think the errors are saved, put on queue if the device is offline. Then once the app is opened once more and then the device is online, those errors are sent.
However, I want to make the experience more seamless for the user and just automatically send the error logs once the user's device goes online.
I checked the Android Docs of CrashLytics, but I didn't find any examples that did what I wanted to achieve.
Is there anything I can do to automate CrashLytics to send the Errors as soon as the device goes online? Maybe something in the declaration or through a NetworkReceiver class that would call a function of the library once the receiver knows the device is online?
I feel like I'm overlooking something simple or I may have missed out on something they said in the website.
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?
I wrote a simple Android app that functions as a digital sign -- all it does is download and display a (simple, static) web page, and it automatically refreshes the web page once every four hours, with no user interaction.
It generally runs fine for days or weeks at a time, but every so often (seemingly at random intervals) when I go down to where one of the units is deployed I find that the app has mysteriously stopped running -- i.e. the device has returned to the Android desktop.
I instrumented my app to emit log messages (both by calling Log.i and by writing text to a separate log file) and I don't see any evidence that the app crashed or that it exited intentionally; it just seems that at one point it went to sleep after refreshing the web page (as usual), and was never heard from again. I also did a "adb shell logcat" to examine the device's system log after the fault occurred, and I didn't see any stack traces; but I'm not sure how far back that log goes.
Does anyone have any idea why an app might mysteriously go away? Alternatively, is there a recommended way to debug this problem? Since it only happens once every few weeks, it's difficult to reproduce the fault. In particular, is there a better way than "adb shell logcat" to view any crashes that may have occurred in the last few days or weeks?