I have Log.d to log some info inside the the source files.
1)Where do you see the output of that Log.d statement? Logcat has way too many process and kernel operations listed just junked up the whole place. I don't need to know all those internal system operations. I only need to list the Log.d statement.
You can specify a filter as described in the 'adb logcat' help output. But you need to also silence the things you are not interested in. For instance, if you specified the Tag as 'MyApp' you can just have logcat dump the MyApp lines using:
adb logcat 'MyApp:v,*:s' which silences everything (*:s) and displays anything tagged with 'MyApp' that is verbose and above. For debug and above use 'MyApp:d' instead.
Related
I am using slf4j-android 1.6.1-RC1 via gradle/maven and when I call Log.debug nothing comes out in Logcat under Android Studio 0.3.5 when I run an application in the emulator.
Just for fun I tried the following:
private final Logger Log = LoggerFactory.getLogger(MainActivity.class);
...
Log.debug("Got this far, woohoo!");
android.util.Log.d("blah","I am here!");
The Log.d's output did appear in Logcat but Log.debug did not.
I checked Log.isDebugEnabled() and sure enough it is set to false. But that seems weird since android.util.Log.d works just fine. Shouldn't slf4j be using the same log level? In fact, shouldn't slf4j just be calling android.util.Log under the covers?
I also replaced Log.debug with Log.error and that did work. So the problem seems to be that slf4j has somehow decided that debug events shouldn't be emitted even though Log.d will emit them.
How do I get slf4j to honor the log level set in Logcat in Android Studio like android.util.Log does?
If you look at the source for slf4j-android, you can see that it calls android.util.Log#isLoggable to decide if the log entry should be made. The javadoc for isLoggable says (my emphasis):
Checks to see whether or not a log for the specified tag is loggable
at the specified level. The default level of any tag is set to INFO.
This means that any level above and including INFO will be logged.
Before you make any calls to a logging method you should check to see
if your tag should be logged. You can change the default level by
setting a system property: 'setprop log.tag. '
Where level is either VERBOSE, DEBUG, INFO, WARN, ERROR, ASSERT, or
SUPPRESS. SUPPRESS will turn off all logging for your tag. You can
also create a local.prop file that with the following in it:
'log.tag.=' and place that in /data/local.prop.
So by default calling slf4j's Logger.debug will do nothing. On the other hand, android.util.Log.d doesn't call isLoggable, and so the log entry is made.
None of the options mentioned in the javadoc are palatable, which rather renders slf4j's Logger.debug less than useful. It'd be nice if the logger could be programatically configured to ignore isLoggable, but at the time of writing this it can't.
See also Does Log.isLoggable returns wrong values?
I found this version much easier to use: http://noveogroup.github.io/android-logger/
You can set the desired log level in an android-logger.properties configuration file. It is not exactly honoring the Logcat log level but at least you can show debug messages without messing around with setprop when using slf4j-android
You can also use https://github.com/mvysny/slf4j-handroid - a special fork which logs debug messages during development phase; it also contains workarounds for bugs in Android Studio 1.5 not logging certain exceptions.
This worked for me. To change the default INFO level to DEBUG for the class that called LoggerFactory.getLogger(MyClass.class), type this at the command line:
adb shell setprop log.tag.MyClass DEBUG
Then all of the DEBUG and higher output for MyClass will be in logcat.
I am a little confused to differenate System.err/out, e.printStackTrace and log while logging RuntimeException.
At first, I thought that log information is not saved in a file if I use System.err/out, e.printStackTrace and just printed on console.
But System.err/out, e.printStackTrace also seem to be logged in a log buffer and we can see it through logcat.
Threfore, if we can save log in a file and also System.err/out, e.printStackTrace results can saved in a file.
Q1. What I understand is right?
Q2. If it is, which logging type is better to debug field issues after production?
Q3. If any RuntimeExceptions occur, where can I find the log file in android folder?
UPDATE
I got an answer for Q3.
In case of android, RuntimeException log seems to be saved in /data/system/dropbox.
With Android, it's more efficient to log exceptions and write messages using the methods in Log. In emulators and on most devices, writing directly to System.out or System.err get redirected to Log.i. On some devices, writes to System.out/err are lost. From the Android docs:
By default, the Android system sends stdout and stderr (System.out and System.err) output to /dev/null.
Using e.printStackTrace also just writes to System.err, and I believe that it is less informative than the Log methods, since you can add a log tag to the latter.
As far as I know, all the logging information, including output from app crashes, is kept in the logs. (If you catch RuntimeExceptions, there is no output unless your code generates it.) You can find the logs, I believe, in /system/bin/logcat; however, it's not in plain text format. You can pull the information off the device in a readable form by attaching it to a development environment and entering the command:
adb logcat -d -v time > logfile.txt
There's also a logcat view in Eclipse. There are also some free utilities (aLogCat and CatLog come to mind) for looking at the logcat data on a device.
What I understand is right?
Your understanding seems fine. Most things written to standard output or error are displayed in Logcat. As Ted Hopp noted, though, it's preferable to use the Log class for logging. This information is not saved to an easily-accessed file by default, but you could perform that step yourself.
If it is, which logging type is better to debug field issues after production?
It's difficult to collect debugging information if you're storing it on the device in a file. If you're deploying your app to the Google Play Store, you can use the Developer Console to view stack traces from your app (provided that your users have opted to send crash reports). A more reliable solution would be to use a service that tracks crashes in the wild and aggregates a lot of useful statistics for you (e.g., Crittercism).
If any RuntimeExceptions occur, where can I find the log file in android folder?
They're not stored in a log file, as far as I know. You could catch each exception and write something to a custom log file (whose location you can choose), but that tends to be unwieldy; the services that I mentioned above will be much more efficient for doing this.
When I test my android app, I log messages that show up on LogCat. But the messages drain out the top of the window quickly making it impossible to read them quickly enough.
How can I stop this?
There's a scroll lock in the logcat window that you can use to pause the printout for a moment.
To get complete logcat messages, you can redirect them to a file:
adb logcat >& output.log
It depends somewhat on what you mean by "drain". If the problem is simply that messages are scrolling by too fast and you need to stop auto-scrolling to the bottom, you can pause this feature in the IDE (or in DDMS/Monitor). HOW you pause it depends on your IDE, in IntelliJ you can just click somewhere in the log output to place a cursor, and in Eclipse there is a button above the logcat window to pause the output scrolling (don't forget to turn it back on or you won't see new messages).
However, if your problem is that so much data is being logged that you cannot scroll up to see what you need even if scrolling is paused, you need to log less. This is because the Android logcat driver is a fixed-size 64KB circular memory buffer. So if you log enough data, it will begin to overwrite the older entries in the log and they will be gone before you've had a chance to read them.
There are some methods:
Disable the auto scrolling feature. Click on the "Scroll Lock" button to disable this.
Use the command line tools. Run "adb logcat | less" and you can navigate for the results. You can also run "adb logcat > logcat.txt" and inspect logcat.txt after that.
Why don't you filter the logcat, so it shows the things your are most interested in.
You can display only the tags you are interested in with the following syntax (using the adb tool from the command line - also available in the logcat view in Eclipse):
adb logcat TAGTOSHOW:* TAGTOSHOW2:* *:s
You can include as many TAG combinations as you want. Don't forget the *.s which silences all the rest.
I prefer teeing to a file:
adb logcat | tee foo.log | grep "YOUR_TAG_OF_INTEREST"
This way you get whatever you think you're looking for in your terminal window, but if you need to look at the full logs you have them saved off in a file.
In my Dalvik Debug Monitor new log messages which have different tag than previous log message are displaying after erasing all previous log messages. That means log is clearing itself all the time and only showing a few lines. What will i do to view all Log messages??
This happens a lot to me too. As far as I know there's no easy way around it but have a look at this python script which I modified (for full disclosure this is the original colored logcat script
- I changed the formatting and tweaked it a bit)
or you could just use the command line:
adb lolcat
or if you're interested in a specific tag, and using unix (or cygwin as I noticed you're on the PC):
adb lolcat | grep TextToFind
P.S. yes I know I'm using lolcat, instead of logcat - both will work. lolcat is just for the lulz
* EDIT *
You can also use logcat filtering to get the data you want from logcat. For example I ususally use this combination:
adb logcat MyAppTag:* *:E
this gives me all the logs which has a tag of MyAppTag and all other error and fatal messages. This is, imo, a better way of doing it than using grep.
I'm using Logcat in Eclipse. I've been unable to find documentation online telling me as such, but presume that the V, D, I, E etc. buttons when clicked should restrict Logcat output to that pipeline? No matter which I select, every logcat output is spewed out, and it's making debugging nigh on impossible.
Can someone please tell me how to display only Debug output, i.e. Log.d(..) prints? I don't think this is possible using a filter, since I've tried creating one with log level 'Debug' and an empty tag and pid field, yet this simply prints all log outputs again.
Many thanks!
UPDATE
So, thanks to Aleadam's link below, I'm now aware that V/D/E/ etc. are 'priority levels' and include those priorities lower than themselves. It doesn't seem possible to restrict to only D(ebug) output, but at least I know how to restrict to D,V since V(erbose) is the only priority level lower than Debug:
adb logcat *:W
Of course, this must be done via the command line, so I'm now going to figure out how to employ the same strategy in Eclipse. The buttons really aren't working for me, I've no idea why, but it's frustrating!
Many thanks for all the information you've posted, guys.
Those buttons should work in the manner you're describing so long as they were logged with the appropriate API call in the Log class. http://developer.android.com/reference/android/util/Log.html
Regexes/wildcards do not work. There's a bug I requested from almost a year ago. http://code.google.com/p/android/issues/detail?id=11580&can=4&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars
adb logcat *:D will not show only debug, but everything with debug priority or higher.
For example, adb logcat *:E > err.log will save errors only.
For many options, check "Filtering Log Output" in here: http://developer.android.com/guide/developing/tools/adb.html#logcat
If you're running under linux use grep. If you're on windows, use the shell: (e.g. adb shell "logcat |grep 'D\/'")
Filtering works on my system but I specify a Log Tag. This then creates a new button next to Log. So for Log Tag "QPR" I see [Log][QPR] buttons and when I press on [QPR] I only see logging that has been tagged as "QPR" as in Log.d(TAG,"onCreate",e);
At least on my system if I click on [Log] (E) I only get errors.
Hope that helps,
JAL