Logcat: reading Android logs on the phone instead of the desktop IDE

A log window that floats over the app you are testing

Logcat answers a narrow problem: reading Android system logs while the app runs on a real handset, without a laptop tethered to it. The project description puts it plainly, presenting a log viewing framework that lets you see Logcat logs directly on the phone. The captured screens in the documentation show the same idea from several angles, a notification entry point, a window entry point, and the log view itself in portrait and landscape.

The mechanism is a floating window. You launch the app in debug mode, grant the overlay permission, and the log output appears on top of whatever is running. There is no initialization call, no static setup method, no configuration object to fill in. The documentation states it directly: no need to call anything, just run it and grant the floating window permission.

That design choice is what separates it from the desktop workflow, where an IDE or an adb session on a workstation streams the same buffers over a USB or network link. A field tester, a QA colleague on a subway, or a developer at a device lab gets a self-contained screen of the logs. The cost is the reverse of that convenience: the person reading logs needs the device in hand and the overlay permission granted, and reading long logs on a phone screen is slower than reading them in a wide desktop pane.

For an Android developer who tests on hardware, that trade is usually worth it. For a developer whose whole workflow is one desktop, it is not obviously worth adding a dependency at all.

One debugImplementation line, three build settings to align

The library is distributed through JitPack rather than Maven Central, which means the remote repository has to be declared before the dependency resolves. For projects whose Gradle configuration is below 7.0, the repository block goes into build.gradle under allprojects:

allprojects {
    repositories {
        maven { url 'https://jitpack.io' }
    }
}

For Gradle 7.0 and above the same repository is declared in settings.gradle, because settings-based dependency resolution management replaced the old project-level approach:

dependencyResolutionManagement {
    repositories {
        maven { url 'https://jitpack.io' }
    }
}

With the repository in place, the dependency itself is a single line in the app module's build.gradle, and the documentation pins the version to 13.2:

dependencies {
    debugImplementation 'com.github.getActivity:Logcat:13.2'
}

Two details are worth reading carefully. The scope is debugImplementation, not implementation, so the library is on the debug classpath only and never reaches a release package. The documentation makes the same point in prose: run it in debug mode, and in a release build the library is not integrated at all.

The same block also sets the Java level, since the framework requires JDK 1.8 or above:

android {
    compileOptions {
        targetCompatibility JavaVersion.VERSION_1_8
        sourceCompatibility JavaVersion.VERSION_1_8
    }
}

There is a demonstration APK for a quick look before you commit to the integration, published on the releases page of the repository.

compileSdk 34 and the AAPT error from a stale plugin

The library carries two build constraints that surface as errors rather than as warnings, and both are documented with a specific remedy.

The first is the compile SDK. If your project's compileSdkVersion is below 34 you must raise it to 34; if it is already 34 or higher, nothing changes:

android {
    compileSdkVersion 34
}

The second is the toolchain. When the dependency is added, a build on an outdated Gradle and Android Gradle Plugin pair fails with a manifest parsing error:

AAPT: error: unexpected element <property> found in <manifest><application><service>.

The cause is stated: the Gradle and Android Gradle Plugin versions in the project are too low. The fix is to move to gradle-7.4-all or newer and to Android Gradle Plugin 7.1.0 or newer. The error message itself is misleading on its own, since it points at a manifest element that a developer has no reason to touch, and the documentation resolves that confusion by naming the real cause.

For a team with a shared build system, this is the part to check first. The library effectively sets a floor on the whole toolchain, not just on the app module. A project pinned to an older Android Gradle Plugin will need that bump before the dependency can even be resolved, and the bump belongs in the build infrastructure work rather than in a feature branch. A project on the Support library, as described later, has a harder version of the same problem.

The log window's actual feature set

The library documents a set of log handling behaviours that go a little beyond showing text. Long pressing a log entry copies and shares it, and logs can be saved to local storage. Long log lines can be collapsed and expanded on tap. Search results highlight the matched text. Logs for a chosen TAG can be blocked, and entries that share the same TAG are merged into a single display group automatically.

Those are viewer conveniences rather than logging features, and the distinction matters. Logcat does not replace a logging framework in your app. It reads the system's log stream, whatever produced it, and presents that stream in a form that works on a phone screen. The save, share, filter and merge behaviours are all about making a stream of system output workable without a workstation, which is the same motivation behind the floating window itself.

The merging behaviour is worth singling out because it changes what you see. When many entries share a TAG, the viewer groups them instead of listing each line, which keeps a noisy component from pushing everything else off the screen. The trade-off is that a grouped view can hide individual entries behind a collapsed group, so anyone relying on an exact line by line reading of a single TAG should check how the group expands in the actual build.

For the mechanics of use beyond the integration steps, the repository points to HelpDoc.md, with an English version in HelpDoc-en.md. The overview lists the highlights but not the full usage guide, so a team evaluating the library should read that file rather than infer the interface from the summary.

The Support library path is documented as temporary

Projects that have not moved to AndroidX have two documented options, and the project states plainly that neither is a good idea. The first is to pin the older dependency line:

dependencies {
    debugImplementation 'com.github.getActivity:Logcat:12.5'
}

The second is to stay on the latest version and convert the published aar package back to Support format using Google's JetifierStandalone tool in reverse mode, working from the releases page.

The wording around both options is unusual for project documentation and worth reading exactly: the project says these are stopgaps, not durable solutions, that later versions of the framework no longer support Support projects, and that the right answer is migrating the project to AndroidX. A migration walkthrough is linked for that purpose.

Practically, this means the library has already drawn a line in the sand. The current release line, 13.x, targets AndroidX, and a Support-era application can keep the older 12.5 dependency or run a conversion tool, but it cannot expect new versions to keep working. That is a maintenance decision for the adopter, not for the library, and it should be weighed against the value of a log viewer.

The repository itself reflects a small, focused layout: an app module, a library module, a jitpack.yml for the JitPack build, and Gradle build files at the root. There is no server component, no plugin channel and no configuration service to manage.

Releases landed in April and May 2026, with a five month gap before them

The version history shows a project that ships in small steps. Version 12.5 was released on 2025-09-03, version 13.0 on 2026-04-05, and version 13.2 on 2026-05-22. The last push to the repository was on 2026-05-22, and the repository is not archived.

The gap between 12.5 and 13.0 is about seven months, and the jump from 12.5 to 13.2 also crosses the Support to AndroidX boundary, which is the kind of change that makes a major version number sensible. The distance from the last push to today is about five months, which is inside the six month window that would make recent-activity claims questionable, but it is still a half year without a commit, so the project is better described by its last push date than by any claim about ongoing work.

The license is Apache-2.0, with a LICENSE file in the repository root. That is a permissive license with an explicit patent grant and a notice requirement, which means the license text and NOTICE handling need to match your distribution process, though the specifics of that are a question for your own legal review rather than something to settle from the repository layout.

Because the library is debug-only, its upgrade cost is low in one respect and non-zero in another. Nothing ships to production, so a version bump carries no runtime risk for end users. But each bump can bring a new compileSdk floor, a new Gradle requirement or a new incompatibility with an old Support project, and those costs land on the build system, not on the app.

Where Logcat fits against the desktop Logcat pane

The competing approach is not another library, it is the workflow you already have. A developer with a workstation runs the app on a device over adb and reads the same Logcat buffers in the IDE, where the text is selectable, searchable across a large buffer, and scrolled with a keyboard. A tester without a computer has no equivalent, and that asymmetry is the reason this library exists.

The difference in approach is the location of the viewer and the cost of the link. The desktop pane needs a host machine and a working connection to the device, and in exchange it gives you a large screen and a mouse. Logcat keeps everything on the handset, drops the connection requirement, and pays for it with a phone-sized display, an overlay permission and a dependency on a third party library.

The interesting middle case is a hybrid. A developer uses the floating window for a quick check during manual testing, then reproduces the problem at the desk with the full IDE pane when the log volume becomes too much to read on a phone. The library supports that combination rather than competing with it, and since it is debug-only, it adds nothing to the artifact that ships.

What the desktop pane does better is worth stating: full text selection, unlimited scrollback retention, and simultaneous views of several devices. What Logcat does better is availability. A team that only ever debugs at a desk will find the desktop pane sufficient, and a team that ships to field testers will find the floating window the only workable option.

Editorial conclusion

Use Logcat when you are debugging an Android app on a physical device and want the log output on screen without a workstation attached, and you are already on compileSdk 34 with a recent Gradle and Android Gradle Plugin. Skip it if your build sits on the legacy Support library, since the documentation calls that route a temporary measure, or if your team standardises on the desktop Logcat pane and never debugs on device. Before you add it, check your compileSdkVersion against the requirement of 34, confirm your Gradle is gradle-7.4-all or newer and the Android Gradle Plugin is 7.1.0 or newer, and read HelpDoc.md for the usage details the overview leaves out.

Frequently asked questions

Official sources

1. getActivity/Logcat on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases