Logcat Reader: an on-device logcat viewer for Android

A logcat viewer that runs on the phone

Logcat Reader is described in the repository description as a simple app for viewing logcat logs on an Android device, and the README shortens that to a simple app for viewing logs on an android device. That is the whole product, and knowing it changes what you can expect. There is no server component, no account and no configuration file, because the data never leaves the handset unless you ask it to. The implementation is Kotlin with Jetpack Compose and coroutines, which the repository topics list explicitly. It is distributed through both the usual channels, with a Google Play listing and a F-Droid entry for the package com.dp.logcatapp, and the README carries the launcher icon and four screenshots covering the dark theme, the light theme, the search screen and the compact view. The licence is MIT, and the project was last pushed to on 2026-05-25 with three releases in the spring of 2026, v2.5.1 on 2026-03-14, v2.6.0 on 2026-03-28 and v2.6.1 on 2026-04-13, so the versioning suggests a steady, small, mobile release habit.

Filtering by app, tag, priority, pid and time

The filtering model is what separates this from a scrolling text view, and the README lists the fields it works on. You can filter logs by app or by package name, by tag, by message, by priority, by pid, by tid, and by date and time. That last pair of identifiers is worth a word, because pid and tid together are what let you separate an application's own threads from the noise of the rest of the system, which is usually the reason you opened a log tool in the first place. Three of the filter fields go beyond exact matching. Message, tag and package name support regex, so a tag filter can be a pattern rather than a literal. A second layer sits on top of that in the form of the search functionality, with highlighting of matches and regex support, so you can find a string anywhere in the stream and see it marked in place rather than having to read past it. The display options include a compact mode, which is what the fourth screenshot shows and what you want when a burst of logs has to fit on a phone screen.

Recording, saving, sharing and exporting

A log viewer is only half a tool. The other half is getting the evidence out of the device, and the feature list covers four ways to do it, record, save, share or export logcat logs. Recording matters most when the interesting event happens once and you did not have the app open at the time, since a persistent reader can capture a window of output and let you go back to it. Sharing matters when a bug is reproducible on someone else's handset and you want them to send you the exact lines rather than a screenshot. The repository does not document the format of the exported files, the retention policy of the saved logs, or whether the record buffer is bounded in any way, so if your workflow depends on pulling a specific window of history out of the app after the fact, that is a question to settle on the device rather than from the documentation. The module layout suggests the log capture and the recording are separated, with a logcat directory and a logger directory at the top level of the project.

The permission has to be granted from a computer

The prerequisite section is the part of the README that decides whether you can use the app at all. Logcat Reader needs android.permission.READ_LOGS, and the documented way to get it is ADB, which means a computer with platform tools attached to the device. The command grants the permission and then restarts the app so it picks the permission up:

adb shell "pm grant com.dp.logcatapp android.permission.READ_LOGS && am force-stop com.dp.logcatapp"

Two things follow. The grant is per package, so the identifier in the command has to match the build you installed, and a mismatch produces no error and no log output, which is the most likely first hour of confusion for anyone trying this. And because the route runs through pm grant, the setup needs a developer mode device and a working ADB connection, which is why the app is useful to developers and developers only. The README documents no other way to obtain the permission, and it does not describe what the app shows when the permission is missing, so assume the empty screen is a missing grant until you have run the command.

The module layout is the architecture

The top level of the repository shows a project split by feature rather than by layer, which is a reasonable choice for an app of this size. There is an app directory for the Android application module, a logcat directory for the log capture and parsing, a logger directory that is presumably the recording and persistence side, a searchlogs directory for the search and filter logic, a collections directory for the saved log sets, and a util directory for shared helpers. The build side is a Gradle project with a root build.gradle, a settings.gradle, a gradle.properties, the gradle directory, and the gradlew and gradlew.bat wrapper scripts, so a clone builds without a system Gradle. There is also a microbenchmark directory, which tells you the author cared about the performance of the parsing and display path, and that matters more than it sounds, since log parsing on a phone is a hot loop when a device is emitting thousands of lines a second. The documentation is spread across README.md, About.md and FAQ.md, and the repository also carries an AGENTS.md file, which usually means instructions for coding agents working in the tree. Continuous integration is configured through a .travis.yml file, which is an older choice than the GitHub Actions workflows most projects use today.

A view on the device, not a log pipeline

The boundary of this project is worth drawing explicitly, because the name suggests a broader tool than it is. Logcat Reader is a viewer with a user interface, filters and export buttons. It is not a log collection agent, it does not ship logs off the device, it does not persist to a server, and the documentation describes no command line interface, no headless mode and no scheduled collection. If your problem is collecting diagnostics from a fleet of devices into a central system, or capturing logs from a build server where no screen exists, this app is the wrong shape of tool, and the platform's own ADB tooling on a host machine is the more direct route since it needs no app installed at all. The trade-off runs the other way too. Reading on the device is exactly right when the bug only reproduces on that handset, when the developer is standing next to it, and when attaching a workstation is inconvenient, and the app answers that case with a filter set good enough to find a specific pid, tag or time window without typing anything.

Editorial conclusion

Logcat Reader fits a developer who is debugging on the handset itself, without a workstation attached over ADB, and who wants to filter by app, tag or priority and then share a log excerpt with a colleague rather than pasting a terminal scroll. It is the wrong choice for CI log collection, for fleet wide log shipping, or for anyone who cannot run ADB against the device, because the READ_LOGS permission has to be granted from a computer before the app can read anything. Before you rely on it, run the pm grant command from the README and confirm the app restarts into a working log view, and check the app id in the command, com.dp.logcatapp, against the build you actually installed, since the grant is per package and a different application id will silently fail.

Frequently asked questions

Official sources

1. darshanparajuli/LogcatReader on GitHub
2. Issues
3. License: MIT
4. README
5. Releases