Best Android logging and debugging tools beyond logcat

This list is for people who already know adb logcat and have hit its limits. maybe you are an app developer chasing a crash that only happens on one handset. maybe you run test automation and need to explain why a run failed at 3am. maybe you look after a small pile of devices and need evidence when one of them misbehaves. I am a Singapore-based operator, so most of my debugging is on real phones that are running things, not on a clean emulator with a debugger attached.

Logcat is the base layer for all of this, and every tool below either wraps it, replaces part of it, or answers a question it cannot. A log line tells you what the app said happened. It does not tell you why the frame took 90 ms, why the battery dropped, or what the system was doing in the ten seconds before the crash. I have ordered the picks by how often I reach for them.

Everything here is free, so the real cost is setup time and how much context you need to read the output. Commands come from the official Android and Perfetto docs, and I name Android versions where behaviour differs.

how I picked

Does it work on a real device over USB or Wi-Fi, not only on an emulator? I debug on hardware first.
Does it answer a question logcat cannot, or make logcat output faster to read?
Can I run it from a script or CI box without a GUI? Headless use matters for automation.
Is it maintained by Google or an active project, as of October 2026? Abandoned tools break on new Android releases.
How much setup before the first useful result? I penalise anything that needs Docker, a server or a custom build.
Does the output survive being attached to a bug report for someone else to read?

the picks

Google: logcat in Android Studio

The Logcat tool window in Android Studio is the first upgrade from the raw terminal. You get filtering by package, log level, tag and free-text query, a saved filter per project, and stack traces that link straight to source. For app developers this is where most of the day goes, and the structured query bar is much faster than piping adb logcat into grep. The official logcat documentation covers the query syntax (tag:, level:, package:mine) and the command line options underneath.

The window is built on the same adb connection the command line uses, so if you want to understand what is happening underneath, my adb protocol deep dive explains how the server, daemon and client fit together.

pros: package-aware filtering, clickable stack traces, saved filters, no extra install if you already use Studio
pros: shows crashes and ANR traces alongside normal output
pros: works over adb Wi-Fi and USB with the same device picker
cons: needs the full IDE, which is a heavy install for a CI box or a tester who just wants logs
cons: the UI changes between Studio releases, so a saved habit or screenshot may be stale in a year

Pricing: free. Android Studio has no licence fee.

Link: developer.android.com/tools/logcat

JakeWharton: pidcat and pidcat-style viewers

Pidcat is a small Python wrapper around adb logcat that filters by application package and follows the process id across restarts. That second part is the trick. When your app crashes and respawns with a new pid, a plain adb logcat --pid=... filter stays glued to the dead process, while pidcat picks up the new one. It also colours by level and aligns tags, which makes a terminal log readable at a glance. Usage is pidcat com.example.app, and you can add -l E to only see errors.

Many forks exist in Go, Rust and Node, so I treat “pidcat-style” as a category: anything that resolves a package name to a pid and reattaches on restart. If you do not want a dependency, the built-in route is adb logcat --pid=$(adb shell pidof -s com.example.app). That works on Android 7.0 and later, where pidof ships with the system. It does not follow restarts, so you rerun it after a crash. Check the pidcat repository for current status before you rely on it, since it is not a Google project.

pros: follows the app across process restarts, which the built-in --pid flag does not
pros: tiny, scriptable and readable in any terminal or over SSH
pros: colour and tag alignment make long sessions less tiring
cons: the original is lightly maintained, so you may be on a fork
cons: only filters logcat, so it adds no new data source

Pricing: free, open source.

Link: github.com/JakeWharton/pidcat

Google: Perfetto

Perfetto is the tool I reach for when the question is “why is this slow” instead of “what did it print”. It records system-wide traces: CPU scheduling, frequency, binder transactions, memory, graphics frames, and your own app’s trace sections. You open the result in the web UI at ui.perfetto.dev and look at a timeline instead of a text file. It ships with Android 10 and later, and the Perfetto docs describe Android 9 as supported with extra steps, so check the quickstart for your version.

A basic capture straight from the docs looks like this: adb shell perfetto -o /data/misc/perfetto-traces/trace -t 20s sched freq idle am wm gfx view binder_driver hal dalvik camera input res memory, then adb pull /data/misc/perfetto-traces/trace trace.perfetto-trace and drag the file into the UI. You can also record from the browser over WebUSB, which skips the command line entirely. Android Studio’s system trace profiler uses Perfetto underneath, so the data format is the same either way.

The first trace is a wall of tracks, but once you can find your app’s main thread and its state over time, jank bugs start to make sense.

pros: answers performance questions logcat cannot, with timing on one shared timeline
pros: command line capture works headless, so it fits scripts and test rigs
pros: SQL query support in the UI for repeatable analysis
cons: steep learning curve, and category choice matters or the trace is empty
cons: traces can be large, and they can contain app and system activity you may not want to share

Pricing: free, open source.

Link: perfetto.dev/docs

Google: adb bugreport

A bugreport is a snapshot of the device, not a log stream. It bundles logcat buffers, dumpsys output for most system services, kernel messages, ANR traces and battery stats into one zip. On Android 7.0 and later, adb bugreport bugreport.zip writes a zip to the path you give. On older devices it produced a single text file. The official bug report guide lists what is inside and how to read it, and also covers triggering one from developer options on the device itself.

The value is that it captures state you did not know you needed. When a tester says “it was weird for a minute”, a bugreport taken straight afterwards has the logcat history, memory state and dumpsys data to check. The cost is that the file is big, so finding the answer means searching. I search for the package name, then for ANR in, FATAL EXCEPTION and lowmemorykiller. If your problem is power, my comparison of dumpsys batteryinfo and batterystats explains which section to trust.

pros: one command captures a wide slice of device state, so you do not need to know the cause first
pros: a single zip is easy to attach to a ticket or send to a vendor
pros: no install beyond adb
cons: takes a while to generate, and the file is large and hard to read without search
cons: contains device and account details, so review before sharing outside your team

Pricing: free, included with adb.

Link: developer.android.com/studio/debug/bug-report

Google: Battery Historian

Battery Historian is a Google tool that turns a bugreport into an interactive timeline of battery related events: wakelocks, alarms, screen state, radio activity and per-app usage. If your question is “what kept this phone awake overnight”, it presents the data much more clearly than reading dumpsys batterystats by hand.

Honest warning: the setup is the barrier. The project is distributed mainly as a Docker image or built from source in Go, and as of October 2026 I would treat it as a legacy tool. Google’s Android docs now steer power investigations towards Perfetto and Android Studio’s profilers, so check the repository for activity before you invest an afternoon. I still keep it for fleet cases where I have a bugreport from a phone I cannot touch again, because the timeline view is quick to read.

pros: clear timeline of wakelocks, alarms and radios from a bugreport you already have
pros: works offline on a file, so you can analyse a device you no longer have access to
pros: good for explaining a battery problem to someone non-technical
cons: Docker or Go build needed, which is more setup than anything else here
cons: not an actively evolving tool, so newer Android releases may have gaps

Pricing: free, open source.

Link: search for “google/battery-historian” on GitHub for the current repository.

JakeWharton: Timber

Timber is not a viewer. It is a logging library you add to your own app, and it earns a place because better logs at the source beat any tool downstream. It wraps android.util.Log, tags lines automatically with the calling class, and lets you plant different “trees” per build type. A debug tree prints to logcat; a release tree can drop low-priority lines or forward only errors to a crash reporter. The usual setup is a single Timber.plant(new Timber.DebugTree()) in Application.onCreate() guarded by a debug check.

The biggest cause of useless logs is inconsistent tags and logging left on in release builds, and fixing that once makes every viewer here more useful. The Gradle dependency I used last was com.jakewharton.timber:timber:5.0.1, but check Maven Central for the current release before copying that.

pros: consistent tags with no manual constants, which makes pidcat and Studio filters actually work
pros: release trees stop debug noise and sensitive data leaking into production logs
pros: small API, easy to adopt in an existing codebase
cons: only helps apps you own and can rebuild
cons: another dependency to keep updated, for something you could write in a few dozen lines

Pricing: free, Apache 2.0 licence.

Link: github.com/JakeWharton/timber

Google: App Inspection in Android Studio

App Inspection is a set of live inspectors inside Android Studio: Database Inspector for SQLite and Room, Network Inspector for HTTP traffic, Background Task Inspector for WorkManager jobs, and Layout Inspector for the view tree. Where logcat shows what the app chose to print, these show what the app actually holds in memory and sends over the wire. I use the Network Inspector for a quick check of what a request really contained, and the Database Inspector when state is wrong but nothing is logged.

A note for UI automation people: Layout Inspector is a different view of the screen than uiautomator dumps. If a Compose element is missing from your test tooling, the inspector often shows it, and my write-up on why Jetpack Compose elements don’t show up in the UiAutomator accessibility tree explains the gap. Inspectors generally need a debuggable app, which limits them to builds you control.

pros: shows live app state (databases, requests, jobs) that never reaches the log
pros: Layout Inspector helps when accessibility-tree based tools cannot see an element
pros: part of the IDE you already have, so no new install
cons: needs a debuggable build, so it does not help with a release app you do not own
cons: tied to Studio, so no headless or CI use

Pricing: free, bundled with Android Studio.

Link: see the App Inspection pages on developer.android.com.

comparison table

tool	price	primary strength	primary weakness
Logcat in Android Studio	free	package-aware filtering and clickable traces	needs the full IDE
pidcat-style viewers	free	follows the app across restarts	adds no new data, patchy maintenance
Perfetto	free	system-wide timing and jank analysis	steep learning curve
adb bugreport	free	full device snapshot in one zip	big file, hard to search, private data
Battery Historian	free	readable battery timeline	Docker setup, legacy status
Timber	free	clean consistent logs at the source	only for apps you can rebuild
App Inspection	free	live database, network and layout state	needs a debuggable build, IDE only

how to choose

Start with the question, not the tool. If you are asking “what did the app say”, use Studio Logcat while you sit at a desk, or pidcat in a terminal when you are on a remote box or want output you can pipe. If you are asking “why was it slow or janky”, go to Perfetto. If you are asking “what was the whole device doing when this broke”, take a bugreport straight away, because the state disappears once the device reboots or the buffers roll over.

If you test on emulators only, you will miss a lot of this. Thermal behaviour, vendor battery managers and carrier networks do not show up on a virtual device, and my Android Emulator vs Genymotion comparison covers where emulators are fine and where they are not. Once you need real hardware at scale, a device farm is the usual answer. One narrow option from my own work: cloudf.one rents real Android phones in Singapore on dedicated hardware, controlled from the browser. adb is not self-service there. adb and Appium reach a rented phone only through a WireGuard tunnel that we set up on request by email to [email protected], so it suits you only if you need a Singapore-based real device and can wait for that setup. It is Singapore only.

If you own the app, invest in Timber or a similar logging wrapper early. It costs an afternoon, and every other tool improves. If you do not own the app, you are limited to logcat, bugreports and Perfetto, and you should only test apps and devices that you own or are authorised to test.

Finally, think about who reads the output. A Perfetto trace or a bugreport can hold app names, account identifiers and system activity, so strip or review before sending it to a third party.

what I left out

I left out commercial crash reporters and hosted log platforms. They are useful, but they are a different category (production monitoring, with accounts and pricing) and the point of this list is local, free tooling you can use over adb. I also skipped older UI-based viewers that predate Android Studio’s current Logcat. I could not point to a maintained version, and I would rather leave a tool out than recommend one that may break. Meta’s Flipper is another one I would check carefully before adopting, since its status has changed over the years and I have not re-tested it recently.

verdict / top pick

If I had to keep one tool beyond plain logcat, it would be Perfetto, because it is the only one here that answers questions the others cannot. For daily work the practical stack is simple: Studio Logcat or pidcat for the live stream, a bugreport whenever something strange happens on a device, and Perfetto when the complaint is about speed. Add Timber if you own the code. Add Battery Historian and App Inspection only when the problem calls for them.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-10-25.