logback-android is logback for Android, and it needs a Context you may have to hand it

A lite logback, with the appenders Android needs

logback-android is described as a lite version of logback that runs on Android, providing a highly configurable logging framework for Android apps and supporting multiple log destinations simultaneously. The destinations are files, SQLite databases, logcat, sockets, syslog and email.

That list is the real differentiator. On Android, logcat is the obvious destination and the others are the ones that matter in production. A file appender is what a user sends you when they report a bug. A SQLite appender is what you use when you want to keep structured log rows in the app's own database and query them. Syslog and email appenders are for an app running on a device you control, such as a point-of-sale terminal or an IoT gateway, where the log has to leave the device.

Because it is a port of logback rather than a new framework, the configuration model is the one logback users already know, and the docs are in a wiki rather than in the repository, with the README explicitly directing readers there for documentation.

The primary language of the repository is Java, the licence is Apache-2.0, and the last push was on 2026-10-12.

Two artifacts, because the JDK level decides the minimum SDK

The JDK-specific builds section explains something that catches people out, and it is worth reading before you add the dependency.

logback-android is published as JDK-specific artifacts instead of a single lowest-common-denominator build:

| Artifact | Bytecode | minSdk | |---|---|---| | `com.github.tony19:logback-android` | Java 11 | 26 (Android 8.0) | | `com.github.tony19:logback-android-jdk8` | Java 8 | 21 (Android 5.0) |

The guidance is to use logback-android unless your app must support devices older than Android 8.0, in which case use logback-android-jdk8.

That mapping is the thing to hold on to. The default artifact needs a Java 11 toolchain, which in Android terms means a recent Android Gradle Plugin, and it drops support for anything before Android 8.0. The jdk8 artifact exists to keep the old device floor, and it exists because the bytecode level of the library is what determines the API level you can claim.

The API badge in the README header says API 21+, which matches the jdk8 artifact, and the README notes that the older 1.x line lives on a separate 1.x branch, so there are three code paths to be aware of if you are supporting a wide device range.

The quick start is an XML file in assets and an SLF4J logger

The setup is the standard logback XML in the app's assets folder, with one Android-specific class name.

The dependencies go into app/build.gradle:

dependencies {
  implementation 'org.slf4j:slf4j-api:2.0.7'
  implementation 'com.github.tony19:logback-android:3.0.0'
}

The configuration file is app/src/main/assets/logback.xml, and the schema namespace is the project's own:

<configuration
  xmlns="https://tony19.github.io/logback-android/xml"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="https://tony19.github.io/logback-android/xml https://cdn.jsdelivr.net/gh/tony19/logback-android/logback.xsd"
>
  <appender name="logcat" class="ch.qos.logback.classic.android.LogcatAppender">
    <tagEncoder>
      <pattern>%logger{12}</pattern>
    </tagEncoder>
    <encoder>
      <pattern>[%-20thread] %msg</pattern>
    </encoder>
  </appender>

  <root level="DEBUG">
    <appender-ref ref="logcat" />
  </root>
</configuration>

Then the code is plain SLF4J:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

@Override
public boolean onOptionsItemSelected(MenuItem item) {
    Logger log = LoggerFactory.getLogger(MainActivity.class);
    log.info("hello world");
    // ...
}

The LogcatAppender is the one piece that is not standard logback, and it is what makes the tag separate from the message so the platform's logcat filter can select on it.

The unit test caveat is real and the README gives two ways out. If you use logback-android in unit tests, you either use Robolectric, or you swap in the desktop logback with a testImplementation of ch.qos.logback:logback-classic:1.2.11 and exclude the logback-android module from the test configuration.

The Context workaround is the part that will break first

This is the section a reviewer should read, because it describes a dependency on an interface Google has been restricting.

In order to support various special properties for the XML config, the code requires access to an Android Context instance. By default the framework uses a workaround based on reflection that seems to work for the time being. However, in view of Google's restrictions on non-SDK interfaces, this code might not work anymore. The framework therefore provides a special API that enables the application to provide an Android context instance that will be used instead of the workaround.

The note is that the context instance must be provided before it is needed by the framework, so the best place for it is in the application's onCreate callback:

public class MyApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();

        // Assuming no logging occurs before this
        AndroidContextUtil.setApplicationContext(this);
    }
}

And if an earlier initialization is required, you might consider overriding attachBaseContext, although at that stage the context instance might not be fully initialized, which might be good enough if it is fully initialised by the time the framework uses it.

One subtlety the README calls out: despite the method being called setApplicationContext, the user may use any ContextWrapper component, such as an Application, Activity or Service, because the framework will actually use the pure application context underneath.

This is the practical cost of the library. A logger that needs the application context in order to resolve properties in its configuration file is a logger that will, at some point, fail to start on a new Android release unless the app has been modified to provide the context explicitly. That is a small piece of code in your Application class, and it is a real coupling to remember.

Building the AAR and publishing it are separate jobs

The Build section is short, and it uses a shell script rather than a Gradle invocation:

git clone git://github.com/tony19/logback-android.git
cd logback-android
scripts/makejar.sh

The output is written to:

./build/logback-android-3.0.0-debug.aar

The Release section then explains what publishing to Maven Central requires, and the requirements are in local.properties:

# output from `gpg --export-secret-keys <PUBKEY_LAST8> | base64`
signing.key=
# PUBKEY_LAST8 from `gpg --list-keys` (last 8 digits of pub key)
signing.keyId=
# password for key (can be empty if key has no password)
# path to secring.gpg file from `gpg --keyring secring.gpg --export-secret-keys > ~/.gnupg/secring.gpg`
signing.secretK

The last property name is cut off in the README, but the shape is clear: GPG key material, a key id and a password, all of which live in a file that should never be committed. That is the standard Maven Central signing setup, and it is the reason the build script exists rather than a plain gradle assemble.

The repository layout backs this up. There is build.gradle and settings.gradle at the root, a gradle/ directory with the wrapper, a logback-android/ module holding the library itself, a config/ directory, docs/, scripts/ containing the makejar script, and logback.xsd at the root, which is the schema the XML configuration is validated against and the same file the schemaLocation in the config points at through a CDN URL.

There is also a .travis.yml and an AGENTS.md, plus GitHub Actions workflows for the build and for CodeQL. The release history shows v_3.0.0 from 2023-03-27, v_2.0.1 from 2022-12-04 and v_2.0.0 from 2019-02-27, so the 3.x line is the current one and the last published artifact predates the recent commits.

Where logback-android is the wrong choice

The first wrong-tool case is a project that wants the platform's own logging. Android ships a logging framework in the platform, and every Android developer already has a logger with no dependency, no configuration file and no Context requirement. A library that needs a context instance to start, for a feature the platform provides for free, is a poor trade for a new project.

The second is a team that does not want logback's configuration model. The whole appeal here is the XML configuration and the appender model, and a team that wants a programmatic logger configured in Kotlin is paying for a format it does not want.

The third is a new app with a high minimum SDK. The default artifact needs minSdk 26, so a project targeting a broad device range either takes the jdk8 artifact with its own constraints, or keeps the device floor low and inherits the 1.x branch, which is a different and older codebase.

The fourth is the maintenance question. The Context workaround depends on reflection into non-SDK interfaces, and the README says plainly that in view of Google's restrictions this code might not work anymore. That is the maintainer's own statement about the failure mode of the default path, and it is the first thing to test on a new Android release, along with whether the app is providing the context explicitly.

For a team that does want on-device logs it can collect, a SQLite appender writing to the app's own database, and syslog output from a device it manages, the library fills a gap the platform does not. That is a real niche and the port does it well. It is just not a general-purpose Android logger.

Editorial conclusion

logback-android fits an Android team that already knows logback and wants the same XML configuration model with appenders such as SQLite files or syslog on device, and it does not fit a project that wants a zero-configuration logger or a maintained upstream standard library. Before adopting it, decide whether to use the Java 11 artifact or the jdk8 one, because the plain artifact needs minSdk 26 while logback-android-jdk8 needs 21, and set the Android context through AndroidContextUtil.setApplicationContext in onCreate rather than relying on the reflection workaround.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. tony19/logback-android on GitHub