Android docs indicate:
The order in terms of verbosity, from least to most is ERROR, WARN, INFO, DEBUG, VERBOSE. Verbose should never be compiled into an application except during development. Debug logs are compiled in but stripped at runtime. Error, warning and info logs are always kept.
But try to do a Log.d() and you'll find it's actually still recording to Logcat on a real device.
Does anyone know why? Or how to disable it?
Thank you!
What you are seeing is expected behaviour. Log.d will always be logged and visible if you use logcat and connect the device. Hence if you dont want debug logs in production app , turn it off. Infact android sdk suggests you do that. This SO answer might help you as well. Should I comment my log calls when creating my final package?
Andriod sdk says
Turn off logging and debugging
Make sure you deactivate logging and disable the debugging option
before you build your application for release. You can deactivate
logging by removing calls to Log methods in your source files. You can
disable debugging by removing the android:debuggable attribute from
the tag in your manifest file, or by setting the
android:debuggable attribute to false in your manifest file. Also,
remove any log files or static test files that were created in your
project.
Also, you should remove all Debug tracing calls that you added to your
code, such as startMethodTracing() and stopMethodTracing() method
calls.
Source
You should encapsulate logging in your own class and enable/disable special types of logs when you need.
if verbose is compiled in dvelopment, it would be funny if debug logs not. So signe your app and give it a try, i think the debug messages are missing then.
When you plug your device it activates the debug mode. I don't think it's doing the same if the app run with the device unplugged, though you can not check that...
Related
Everything works in Debug Mode but Crashes in Release Mode. What required permissions are available in Debug Mode that are not turned on in Release mode?
EDIT
When I set Linking to None, I get past the first screen to my Login screen. However, when I added the Release permission Internet, the first time it tries to read a remote Entity Framework Core Table it crashes.
EDIT 2
In Release Mode, if I check Use Shared Runtime, the app runs fine.
EDIT 3
I have turned on Debugging while in Release mode Temporarily. The Following line throws a System.TypeInitializationException only in Release Mode:
if (_context.bma_users.Any(p => p.username == _name.Text) && _name.Text != string.Empty)
IF YOU JUST WANT TO SEE THE CRASH LOG:
Assuming you have Android Studio and no crash report service implemented (Firebase, Crashlytics, etc...)
You might want to see the crash log print first:
Open the Logcat in Android Studio.
Change Log Level to Error.
Make sure USB debugging is enabled on your device.
Connect your device to the computer.
Make the app crash and see what it prints.
If you can't reproduce:
Next time it crashes, connect the device and do the same as above. Usually the log history will be available to view, scroll until you find the crash :)
Look for FATAL EXCEPTION
Keep in mind - using the Logcat search bar can clear the log history, in most cases you can reconnect your device to view it again.
You already assume "permission", not sure why...
The first thing I disable when I have something crashing only in release mode is minify (aka ProGuard). So disable the obfuscation, build again and try to see if you still get crashes. If not, reenable proguard one line at a time to pinpoint the cause.
The answer was to set Additional supported encodings to West in the Android Options screen under Project Properties. It doesn't seem related but I was trying every possible combination and this finally worked.
You can just set debuggable: true for your release build type.
Don't forget to remove this property once you're done with debugging.
Go to the properties of the android section and then into the Android options tab.
Make sure that the "Use Shared Runtime" and "Use Fast Deployment" boxes are unticked in your release configuration
You can use any of the crashlytics tools like Firebase Analytics, Fabric, Splunk Mint to get the exact crash log
Please check crashlytics they mention exact line number where your app was crashing. You can see what error is showing, then you can fix.
I am a novice to the Android Studio and working on one group project.I am trying to log some variable values to logging.
When I use Log.e values are properly logged. While when I use Log.w or Log.v nothing gets printed. Here I am switching from logcat from error to verbose and to warning as I am using Log but still can't see anything printed.I previously used Toast but heard that using it might make my app slow and using Log.e everywhere is not a good practice.So how to print logs of lower priority?
I tried referring following resources but didn't find anything that could help me enabling logging for lower priority Logs, Just got the info that for some reason lower priority logs are disabled.
https://developer.android.com/reference/android/util/Log.html
Android Log.v(), Log.d(), Log.i(), Log.w(), Log.e() - When to use each one?
Thank you in advance.
All logs are always default enabled.
I think you are viewing logs in error view.
Check
You are viewing logs in Verbose
Your filter is set to selected app.
You have selected your app not other app. (where in below image no debuggable process is written)
Android Log.v(), Log.d(), Log.i(), Log.w(), Log.e() - When to use each one?
Log.e: This is for when bad stuff happens. Use this tag in places like inside a catch statement. You know that an error has occurred and therefore you're logging an error.
Log.w: Use this when you suspect something shady is going on. You may not be completely in full on error mode, but maybe you recovered from some unexpected behavior. Basically, use this to log stuff you didn't expect to happen but isn't necessarily an error. Kind of like a "hey, this happened, and it's weird, we should look into it."
Log.i: Use this to post useful information to the log. For example: that you have successfully connected to a server. Basically use it to report successes.
Log.d: Use this for debugging purposes. If you want to print out a bunch of messages so you can log the exact flow of your program, use this. If you want to keep a log of variable values, use this.
Log.v: Use this when you want to go absolutely nuts with your logging. If for some reason you've decided to log every little thing in a particular part of your app, use the Log.v tag.
Explanation by link Kurtis Nusbaum
Update:
If above things does not work then you are facing an device setting issue. Some mobiles have set default log level to DEBUG or ERROR. Allow logging from phone setting.
You can check if log is loggable by Log.isLoggable()
Check
Settings -> Accessibility -> Developer options -> advanced logging->set "Allow all"
or
Settings->Accessibility - > Developer Options -> Performance optimization -> Advanced logging -> set "Allow all"
or for other phone search in "developers options": option "logging" and set "all".
also you can use Log.wtf when your Log.d is not working.
try restarting android studio also
I've searched for similar problems, but I didn't find anything useful - I'm working with eclipse, and I can't see my Logs.
The device is connected properly, the app runs and does what it's supposed to do, but I get no logs from it.
I get other logs messages from the device, not the ones that I print, e.g. Log.d("SMS", "hello"). On the other hand, if I use the statement System.out.println("hello"), I do see it, tagged as System.out.
I've tried to disconnect and reconnect the device, restart it, close and open eclipse, choose the device from Device window. It happens both with a 'real' device and an emulator. I've also tried to remove the filtering, but nothing helps - I still don't get the logs.
Okay, I've found the problem -
Apprently there are some illegal tags, and I've used one of them.
My app is spam SMS blocker, and I've used the tag SMS. If I change it to another tag (like SMSBlocker) it suddenly appears in the LogCat.
Check if your project is using proguard.
Basically proguard will remove all the debug logs and optimize your code while creating apk.
Try adding proguard.enabled=false in your project.properties
I think you should use TAG.
When you log from your android app, the first parameter is a TAG string. So if you set it up to a unique string (like your app name) then you can later filter by it in Eclipse.
Example : Log.e(TAG, "state error");
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.
My boss hopes that there is no information leak when users use our android apps.
And I found even I set the android:debuggable="false" it still can see my logs from Logcat or command line.
I searched android:debuggable someone also have the same problem.
I got some answers from internet, such as next:
There are a property called debugable of Avd. You can print by adb
shell get prop. I don't (know) if it is the cause of your problem.
If you have a pre-production device, you
can still debug an app that has debuggable set to false.
I just think, even I delete all my logs, there are also many logs about my app from OS.
My questions:
1.Is there a way I can do let my "android:debuggable" work well and
2.Is there any other way to hide all my logs except delete all my logs?
3.What does "android:debuggable" really mean?
4.What is "a pre-production device" when it goes on android device?
Thank you for your help. I will try some other ways, and try my best to share my information in here.
I simply create wrapper functions around Log that first check the value of a static boolean called loggineEnabled if it is set to true then log gets called otherwise the calls to log are ignored.
Then I simply set this variable to false before I compile a version of my app that I distribute.
void LogD(String msg){
if (loggingEnabled)
Log.d(MyTag, msg)
}
Is your code guaranteed to be bug-free? If not, why do you want to stop users having information that they might be able to use to shed light on bugs in your app?
Come back when you can write bug-free code, then we’ll talk.