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.
Related
Sometimes when a phone connects to Android Studio, it will print logs between the time it was last connected to Android Studio and the present. This is cool, but I can not replicate it. Some times it happens, sometimes it does not.
I have a guess that this is a feature of USB and wireless debugging, and that logs are put in a temporary file so they can be sent to logcat when reconnected. If so, how do I keep the USB debugging from turning off when testing my device in the field during the day, so I can get the logs that were printed during the day? If not, what is happening?
The logs are nothing to do with Android Studio (or logcat in general) - it's just system logging happening on the device, and that happens whether it's connected to a log-reader or not.
At a guess, what's happening is your app's process is being closed, so the next time it runs it gets a different PID (process ID). When you connect it to the computer, your dropdown shows the currently running app process, and filters by its PID, so you don't see the old stuff.
You've probably seen this while debugging - if you re-run your app, the log "clears" and gives you a fresh one for the new run of the app. The old log messages are still there (as well as a hell of a lot of other logs for all the stuff going on on the device - it is noisy), it's just that you can't see them.
The simple thing to try is going to the filter dropdown on the right of the logcat window, and choose No filtering. Then in the filter query thing next to it (with the 🔎) type the name of your app, maybe its package. It's not perfect but it should show you all of the logs it has from your app, along with a bunch of system stuff that's also referring to it. You could get clever with PIDs or setting up a custom filter in the dropdown to get better results.
You might also be interested in the guide (with some filtering tips) and the commandline version if that's more useful to you
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)
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 ).
I am trying understand some concepts about android device startup ,I want to know that is there any way that I can get a log of applications that get started on device Boot-up ? How can we get that ?
I also want to know that, Is it possible to write an application that gets started at first after boot-up and stop certain apps from getting started on boot-up ?
Is there any IntentService that we have to write ? or this is not feasible unless we have root access ? Please help me in understanding this concepts.
The device log is kept in a buffer, so the most recent entries will be there. If you are early enough before the buffer gets overwritten you will get it since the device booted.
You can access it using
$ adb logcat
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.