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?
Related
I am developing two apps:
-> App A: it connects to a Bluetooth device, retrieve some data, process this data and broadcast an intent to App B
-> App B: it receives this intent and shows the results.
App A must keep running in order to keep sending data to App B.
Everything was working fine until this week when I made some visual changes and update my android device to V7.0.
Now, My App A stops (DEAD message in debugging window in android studio) when I switch to App B and see the results. If I change back to App A, current activity restarts itself and it works normally once again.
I do not get any exception or error message in android studio's debug window.
Any idea or information about this issue. I must say I have read a lot of questions and documentation but I can not find the reason of this issue.
(sorry for bad English)
Everything was working fine until this week when I made some visual
changes and update my android device to V7.0.
7.0 has introduced numerous changes aimed at improving battery life. Your App A is likely suffering from these changes, particularly if it was memory / cpu intensive, which it sounds like it might be.
App A must keep running in order to keep sending data to App B.
If that's the case, you probably want a make App A a foreground Service to ensure it keeps running.
Architecturally this probably makes more sense anyway if your use case is to have App B open while App A keeps piping data to it. The fact that your App A was not dying before was likely just lucky chance. It would have been killed by the system eventually after going into the background.
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.
I have an app that Samsung Smart Manager is complaining about. It reports that the app is causing the device to run slowly but then references the number of errors in a week. It's not entirely clear that "errors" in this case actually mean crashes but it's possible as I think this device might have had QA versions of this app installed.
How do I determine anything about why Smart Manager would show this message about my app? And why does it report causing the app to run slow if it's just errors/crashes?
Here is the full message:
"This app is causing your device to run slowly. To improve your device's perfomance, turn off auto open for this app.
41 errors occured in 1 week"
After a LOT of searching and investigating I think I've figured it out. Note that this is not definitive but it's the best I can dig up.
It appears that this message is only referring to an app crashing and the app has to crash a certain percentage in order for the notification to show up. So it has nothing to do with causing the device to run slowly...
The algorithm for determining if the notification should show up is something along the lines of:
if(crashes >= ((NumberOfTimesUserLaunched + 1) * 10)) -> Show notification
I don't have any information at the moment as to how it determines how many times the user launches it. (If the app launches at boot that may or may not count towards that number)
I work on an app that runs fine on most Android devices; however, sometimes a user complains that the app repeatedly causes his device to freeze such that he has to pull the battery. What can I do to get a log file from this user so I can figure out what caused the freeze? Ordinarily we ask users to repro a crash and run CatLog immediately following to get a log; however, in this case running CatLog after the battery pull doesn't seem to get us any useful information in the log.
Ask him to hit home and wait a minute or two.
If the device is slow, it might look frozen but it will respond. Android is designed to be robust.
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!