-
-
Notifications
You must be signed in to change notification settings - Fork 174
logback-android and logback are fundamentally the same, except logback proper uses language classes that are not available to Android; and thus those are either rewritten or ommitted. Plus, logback-android has features that are specific to Android (e.g., LogcatAppender).
Most (if not all) core features from logback are carried over; but the following features are NOT supported in logback-android:
logback-access- Groovy configuration
- Janino configuration (conditionals in XML, etc.)
- JMS, JMX, JNDI, and Servlets
Other miscellaneous features may be disabled in logback-android (such as the classpath-multiplicity warning at initialization).
logback-android includes the same features as os.android.Log via LogcatAppender, but can do much more. For instance, logback-android supports several different types of log destination, including files and sockets, that can be configured by an external XML file after deployment.
x.x.x-N
where x.x.x is the version of logback proper from which this version of logback-android is based; and N is an integer, starting from 1 and incremented with each release.
For example, logback-android-1.0.6-1 and logback-android-1.0.6-2 are based on logback-1.0.6.
As of v2.0.0, -N is no longer used in the version.
I try to keep them in sync as much as possible, but schedules can slip (sorry).
Feel free to submit a pull request. Or attach a patch to an enhancement request in JIRA.
You can enable debugging messages during the configuration phase, which prints to stdout (tagged with System.out in logcat), using one of the following methods.
Turn on the debug attribute:
<configuration debug='true'>
...
</configuration>OR from code:
LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory();
OnConsoleStatusListener.addNewInstanceToContext(context);OR from an Android shell, set the logback.debug property:
$ setprop logback.debug trueNote: The last method enables debugging for all applications on your device that are using logback-android, which might be too noisy if they're simultaneously active.
Alternatively, you can print the internal status messages on-demand with StatusPrinter. You'd want to avoid this if you're already watching the status messages in real-time with the debug flag mentioned above. Doing both could produce confusing output as status messages would print twice (once in real-time, and again on your call to StatusPrinter).
configureLogbackDirectly();
// print the status messages collected during configuration
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
StatusPrinter.print(lc);Why isn't logback-android printing any messages at initialization even when I've intentionally added syntax errors?
It sounds like logback-android can't see your file. To troubleshoot the problem, you can turn on debugging.
The XML file at assets/logback.xml is read on the first call to org.slf4j.LoggerFactory.getLogger(…) from your application code. If it doesn't exist, logback-android silently does nothing (and logging is disabled).
This exception indicates that these network-dependent appenders were invoked from the main thread (e.g., by logging statements) while your Android application has Strict Mode enabled. You can work around this by using these appenders via the AsyncAppender, which calls the appenders asynchronously thereby avoiding the exception.
Verify both <fileNamePattern> and <file> are absolute paths to writeable locations. A common mistake is to use just a filename in <fileNamePattern>, incorrectly assuming that the file is written to the same directory as the path specified by <file>.
You can also turn on debugging to see what's going on.
Why doesn't logback-android pick up the changes I just made to logback.xml even after I restarted my app? Is auto-config broken?
Auto-configuration occurs only once at initialization when the first logger in your application is instantiated. Android doesn't necessarily end the application when it disappears from view. In order to restart the app (and thus reload the auto-config), you must first kill the app. You can use a TaskManager app or adb (the kill command).
Verify that you have write-permissions for the specified file location.
Make sure to specify the absolute path to a location that your application has write-permissions.
To write to the SD card, your application must have the WRITE_EXTERNAL_STORAGE permission.
Solution for users with Android 6+ is here.
The LogcatAppender is recommended over ConsoleAppender, but you may still use the ConsoleAppender if you wish.
The ConsoleAppender writes to stdout, which is normally suppressed in devices (but is redirected by default in the emulator). The Android documentation provides instructions to redirect the output of stdout to logcat with priority INFO. Also make sure your logcat filter allows the INFO level.
Verify your application has the INTERNET permission.
Verify you have the javamail-android libraries in your application class path.
Double-check your logback-android configuration. By default, SMTPAppender buffers up 256 log entries and sends only ERROR-level messages. So, you wouldn't see the email until you've logged at least 256 errors. This is meant to prevent flooding the recipient's inbox. You can change this threshold by setting the <cyclicBufferTracker> property and by using a TriggerEvaluator, as described in the user manual.
The logback-android binaries are released without debug symbols to reduce the JAR size. You'll need to recompile with the debug profile (mvm -Pdebug package) to get debug symbols and line information in order for breakpoints and stepping to work properly. You can also check the SNAPSHOTS repository, which normally contains JARs built with the debug profile.