57

My question seems to be easily answerable, but there are several good solutions. I like to choose the 'best' one.

Available frameworks (feel free to suggest more):

Pros/Cons:

Androlog:

  • Pro: Similar to Android logging framework, so there are only small changes in the existing code; Able to send crash reports with more detail in the error report (the logs around the exception); Nice logs
  • Con: No standard java "getLogger" approach; Production configuration achievable by uploading property file to sdcard; I need to call init logging manually; Need to create LOG_TAG like constants, or hack it to create log tag constants by Aspect to achieve the standard behavior: tags are the class names; When logging is a business requirement, we need to test it. Testing static calls on Android nearly impossible; Logger can not be injected by framework

Log4J-Android:

  • Pro: Standard way to log in Java; Compatible with SLF4J; Able to parse property files;
  • Con: No built-in crash report system; Seems to me: its not commonly used, so it might me dangerous to use it;

SLF4J-Android:

  • Pro: Seems to be developed by more people like Log4J-Android; The logger.debug("Some log message. Details: {}", someObject.toString()); is a good, and effective way to skip string concatenations if the logger is turned off; lightweight logger binding that delegates to android.util.Log.
  • Con: Auto generated log tags that are <= 23 characters long due to a length restriction of log tags on the Android platform (e.g., com.example.myapp.MyClass tag translated to c*.e*.m*.MyClass), which can result in the same log tag for different classes (e.g., com.example.app.MyClass and com.example.anotherapp.MyClass both translate to c*.e*.a*.MyClass); No built in crash reporting system.

Besides of these, I like Androlog behavior, but I'm a Java dev, familiar with log4j/slf4j. We will definitely need crash report system, but there are several frameworks for crash reporting (beside of android default crash report).

I can combine some of them, for example use Log4J android, but create an appender to use the androlog framework, but sooner or later it will be a mess, which should be avoided.

Thanks for your suggestions, I hope the results will help decide others in the future.

Edit: As mentioned below, I can combine for ex: log4j-android with slf4j (whitch I prefer to do if I'll use log4j, because the log formatting support ("{}",...) ), but it does not answers the question. I have to choose a framework, then I can decorate it with the SLF4J facade.

Thorsten Möller
  • 33
  • 2
Marcell
  • 973
  • 1
  • 6
  • 13
  • From your description, Androlog sounds best, but I see that it requires Maven. I hesitate to add another dependency to my setup without significant benefits. – Tom Jun 07 '12 at 17:25
  • No mention of the Android built-in logging framework? – Piovezan Oct 04 '13 at 13:16
  • 23 characters limit is not SLF4J shortcoming, it's Android restriction. Other logging frameworks cannot do that as well. SLF4J at least, mentions it in docs, and tries to shorten it. – Dzmitry Lazerka Dec 14 '15 at 03:29
  • if you are using kotlin, it is also possible to use: https://github.com/MicroUtils/kotlin-logging – oshai Aug 18 '16 at 18:14
  • Timber https://github.com/JakeWharton/timber – k4dima Dec 08 '22 at 20:23

3 Answers3

13

The better way. I think, is to use SLF4J API + some of its implementation.

For Android applications you can use the following:

  1. Android Logger is the lightweight but easy-to-configure SLF4J implementation (< 50 Kb).
  2. LOGBack is the most powerful and optimized implementation but its size is about 1 Mb.
  3. Any other by your taste: slf4jandroid, slf4j-android.
stefan.nsk
  • 1,755
  • 1
  • 16
  • 12
6

Please check this first answer

It says:

SLF4J is basically an abstraction layer. It is not a logging implementation. It means that if you're writing a library and you use SLF4J, you can give that library to someone else to use and they can choose which logging implementation to use with SLF4J e.g. log4j or the Java logging API. It helps prevent projects from being dependent on lots of logging APIs just because they use libraries that are dependent on them.

So, to summarise: SLF4J does not replace log4j, they work together. It removes the dependency on log4j from your library/app.

Community
  • 1
  • 1
silwar
  • 6,470
  • 3
  • 46
  • 66
  • Ok, I know it. The thing is SLF4J-android library IS NOT directly compatible with Log4J-android, they both contains implementations. (but changing from one to the other is easy). Check the links to the projects. – Marcell May 09 '12 at 10:51
  • Hi Marcell, Androlog is my first preference but as you said it doesn't have java like getLogger approach, I think its better to combine some of these frameworks. – silwar May 09 '12 at 11:05
  • 1
    The repo I linked is a simple SLF4J Logger wrapper library, uses Androlog as the output. With this you get the wrapped Logger from the LoggerFactory.getLogger(). My preference is also Androlog. See: https://github.com/kovmarci86/slf4j-androlog/blob/master/slf4j-androlog/src/main/java/com/mkovacs/logging/anrolog/AndrologLogger.java – Marcell Mar 19 '13 at 08:27
  • Got more info from this, but I'm looking for logger lib which will collect all logs and updates in to server/cloud or into a file which is really helpful! I guess I need to post it as a separate question! – LOG_TAG Sep 14 '13 at 08:52
2

I have tried original slf4j.org-android but unfortunately this jar was not able to get debug/verbose messages to be logged because it internally uses LOG.isDebugEnabled() for debug output wich seems always to be false.

currently i use the alternative lp0-slf4j-android implementation that uses a properties-file with the logging settings where i can also get debug/verbose messages if enabled.

k3b
  • 14,517
  • 7
  • 53
  • 85
  • 1
    about isDebugEnabled() always returning false. The default log level on Android is Info. If you want to see more output from your own logs, you need to enable debugging logging explicitly. See: http://developer.android.com/tools/debugging/debugging-log.html and http://developer.android.com/reference/android/util/Log.html. Basically, you have to enable debug or verbose logging at runtime if you want to see isDebugEnabled() return true. – Anne Gunn Aug 08 '14 at 11:57
  • how can i enable `isDebugEnabled()==true` at runtime? in the links you provided found no infos about that topic. as long as the original slf-original depends on `isDebugEnabled()` and i have no way to enable it at runtime it is useless for me. – k3b Aug 09 '14 at 07:13
  • 1
    I have created https://github.com/mvysny/slf4j-handroid exactly for this purpose, to avoid tinkering with Android settings. – Martin Vysny Nov 27 '15 at 11:58