In my limited experience on a handful of Android devices, if an app crashes with an unhandled exception then that exception's written to the log. However I've come across a Samsung i8160 that doesn't. Other i8160s with various ROMs do. In fact, from boot, it doesn't log anything. It originated on eBay so the history is unclear, but rather than assuming it's an odd ROM and flashing something else I figured it was worth persisting in case the problem arises again elsewhere.
In researching, the first thing to try was to 'dial' *#*#2846579#*#* but this isn't recognised- it just tries to really dial that. There's a shorter *#9900# that does pop up a menu, but that only lets me dump the log and other info to files in /data/log for export. Since logging isn't up from boot, that doesn't export much.
Initially, /dev/log doesn't exist. One suggestion to fix this was to try logcat-enable from a shell. This isn't found. Another suggestion was to manually load the logging module by running insmod /lib/modules/logger.ko from a rooted shell. This brings logging up, but when an app crashes, all logcat outputs is
I/dumpstate( 8074): begin
I/dumpstate( 8074): done
I've found the dumpstate files, which include the logcat output, but there also it just notes creation of the dumps, not the exception that caused it.
As well as starting the module, I'm assuming somewhere there's some configuration determining what actions to take when an app crashes, and here it's not set to dump the exception and stack trace to the log because whoever did it figured logging wouldn't be running anyway. But I can't find anything like this. Does anyone have any ideas on how to progress further?
Some apps have a "report" function inbuilt in case their app crashes. When you choose report on the ANR message, usually a log is created for sending it to the developer. Maybe you can get an app to crash and catch that log (or maybe make your own one)
Related
My LogCat is often not showing null pointer exceptions..
Sample:
ProgressDialog pd;
ps.show();
Application stops (do not reacts for any action), but there is no information about any reason in logcat.
Another sample is with database - if there is no DB and I'm making actions on it, the same happens.
I tried (that action with DB) on my colleague's phone and there was normal error. I have all needed programmer options in my phone turned on.
Maybe someone know , why it is so? It was not burdensome, when I had small app, but now when it's bigger, it can be really frustrating.
I get this with android studio too...
Close android studio, restart ADB, and generally it starts working for me.
If that does not work then put a breakpoint at the line .show(); ... Then open up the logcat and then skip over the breakpoint. It then shows, I have similar issues.
(Windows 7 64 bit - Android Studio 0.82)
I dont like the IDE logcat option honestly.
The SDK comes with an adb binary, use the logcat option from there via
adb logcat or my personal favorite built in alias, adb lolcat
This will give you the log information for EVERYTHING happening on the device, and can be useful tracking down issues caused by device state.
For example, you can see network changes in the logcat, and if your app crashes on network call you wouldnt have any idea why if you just used the logcat output from your app.
In my case I was using: Thread.setDefaultUncaughtExceptionHandler in my application file. If that is not turned off during debugging you won't see any exception output. ( Just make sure to turn it back on again when you release so you can still handle your issues ).
When testing on a device in Android Studio you get an awful lot of output in the logcat.
I'm only interested in the output for the app I'm developing. I can see just this, after running, by opening the Devices section and manually selecting my apps process. Problem is, it's pretty tedious to do this every time I run my app, which seems to be the case.
Is there a way to get it to remember this setup?
How about a way to get it to stop reporting anything after I'm done with my app or it's crashed ? (otherwise my app specific stuff gets buried so quickly by output from other proccesses on my phone)
I'm open to other ways of filtering the logcat too, however I couldn't think of a way to set up filters so that I would get my tagged Log messages AND other exceptions I wasn't expecting.
Any suggestions?
Normally this is done by default, but if not,
in logcat, the green plus sign, when you click it you get a dialog, fill the byApplicationName with your package name, and also your filter name with something, now you can filter your output according to your app
with that beeing said, sometimes you don't get the filter column info (application name) in logcat at all (blank), here (and I my self don't know the cause of it) just forget it for a while and retry again
I have an android application that I have recently finished. So I have successfully finished each function and ensured that no errors are encountered.
When I have exported it to an apk file. It runs smoothly. It uses httpRequests to communicate with a remote mySQL server. But there are times that it spontaneously crashes?
For example, I have an activity that would receive input from the user then communicate with the server. It runs smoothly and quickly. But on next run it would crash. And when I restart the application it would run smoothly again even on the second run. I'm just going crazy from this. Are there any explanations for these?
Use ACRA to collect crash reports from your app. You don't need your own server, just a Google Docs form. The integration is described here:
https://github.com/ACRA/acra/wiki/BasicSetup#wiki-Setting-up_your_project
The advantage of using a crash report tool vs. logcat is that you don't need physical access to the device. There are also chances that you see crashes that you or your testers didn't even notice.
The first step to debugging your problem is to get a stack trace. If you can reproduce this on your own device, then right after you see a crash, connect it to your dev pc and run this command:
adb logcat > crash.log
Open the log file, copy and paste its contents on http://pastebin.com/ or similar and add the link to your question. Once we have that, we can try to figure out what's going on.
I have an application which is mostly native code written in C: Simon Tatham's Puzzles. When I catch a crash (with a signal handler), a Java backtrace will only tell me the vague area of the problem:
W System.err: at name.boyle.chris.sgtpuzzles.SGTPuzzles.resizeEvent(Native Method)
W System.err: at name.boyle.chris.sgtpuzzles.SGTPuzzles$1.handleMessage(SGTPuzzles.java:126)
W System.err: at android.os.Handler.dispatchMessage(Handler.java:99)
What I need in order to have any hope of diagnosis is the native backtrace that the Android framework writes to the log:
I DEBUG : #02 pc 0003e8ae /data/data/name.boyle.chris.sgtpuzzles/lib/libpuzzles.so
I DEBUG : #03 pc 0003ed62 /data/data/name.boyle.chris.sgtpuzzles/lib/libpuzzles.so
I DEBUG : #04 pc 00059060 /data/data/name.boyle.chris.sgtpuzzles/lib/libpuzzles.so
As far as I know, Android Market's crash reports don't include native traces... do they?
Therefore, I currently have my own crash catcher and reporter, described in this previous question, which will offer to drop you into an email compose window with your log in it. That works well enough, with one problem: users don't read (or don't believe) the explanation in the package description and are scared away by the permission request.
It's not these few comments that bother me, it's the unknown number of people who ran away without even installing it. :-(
So how do I get a native backtrace on crash without making the game require a scary-looking logs permission? Possible solutions include:
I'm wrong and Android Market will actually give me native traces these days?
Recommend when I catch a crash that people immediately install and run Log Collector? This is what I'm leaning towards currently. Anyone got a good example of this being done, with well-written explanatory text?
Having caught the crash with a signal handler (which I can do), any way to read my own native stacktrace? More difficult on Android/Bionic than on glibc platforms, no backtrace() available. Edit: Most things under here appear to be required: http://github.com/android/platform_system_core/tree/master/debuggerd - to include enough of it in the project would be overkill, bloaty, difficult, unsupported, brittle on ABI changes/additions. Doesn't seem like a good use of time.
Edit: From Jelly Bean onwards, neither you nor Log Collector can read debuggerd's output, because READ_LOGS went away. :-(
But, Play Console's crash reports now include native stack traces (at least as of late 2014), which makes this all much less necessary.
Previously:
I shall give my answer in the form of a git commit:
https://github.com/chrisboyle/sgtpuzzles/commit/e9917f1ffe93f9d9963463db849e3768beafccee
This is delegation to Log Collector, as I hinted at above. I catch the crash as before (see my previous discussion of how to do that) show an "oops, I crashed" screen as before, and if the user clicks Report, then I prompt them to install Log Collector if they haven't already.
If I've sent the user off to install it, as soon as it finishes installing, I catch the PACKAGE_ADDED Intent and launch Log Collector with appropriate options (I warn that I'm going to do this). This is so that the user isn't left guessing that they should click Open, which would launch it without my destination, subject, and filters.
The filters are worth having, as they limit what is sent in the email to lines that might be relevant. This saves the user's bandwidth and my inbox capacity, and means the user can more easily check that there's nothing sensitive in the log and is therefore more likely to agree to send it.
There is another way to access all logs without any special permissions, but it requires enabling remote debugging on the phone. Take a look at the open source rootless Logcat app.
Sometimes I see my app in DDMS restart.As I see it's process id changed.(I'm not sure that,because I don't write log for application oncreate.)
That behaviour ofen happened when I mount SDCard to share USB mode.I'd like to see what happend after mount in my application.So I debug my App,but unfortunately.When mount to share USB mode,application's process id changed and debug been auto stopped.
Why?What happened?What's the strategy for android handle application restart?
And there is another question.Why does sometimes an activity occur an error,thrown an exception dialog,and restart it.Sometimes the android platform just kill the activity and exit.
Maybe it's not a very useful question for develop.But I'm really missing,I want to know the answer.Please help me,friends.Thank you very much.
I used to get into similar cases like yours, what I did to handle and detect is like:
1. Check Device: sometimes devices mal-functioning really cause problems, a bad USB cable will really do restart Android/application.
2. Collect Log: after application restarts, just collect the log from system/event/radio/dumpstate... remember the time when app started to restart then check in log files to look for the causes.
Well, that's my experiences and it works, not in all situations but most of the time.