Home Page » News » How To » How to Capture Continuous Logcat Output for a Specific Android App Using ADB (Step‑by‑Step)

Capture Continuous Logcat Output for a Specific Android App Using ADB

10 min read Learn how to record live logcat output for a single Android app with ADB, filter the logs, save them to a file, and troubleshoot common issues. September 29, 2026 00:30

When an app misbehaves, the most direct way to see what the system and the app are doing is the logcat stream. Capturing the full, continuous log for a single package helps you isolate crashes, ANR (Application Not Responding) events, and permission problems without wading through unrelated noise.

Before you start

Computer with ADB installed – Windows, macOS, or Linux. If you haven’t installed the Android SDK Platform‑Tools, download them from the official Android developers site and add the folder to your PATH.
USB debugging enabled on the device – Settings > About phone → tap Build number seven times, then go to Settings > System > Developer options > enable USB debugging.
A good quality USB‑C or micro‑USB cable – Data‑transfer capable, not just a charging cable.
Enough free storage on the PC – Log files can grow quickly; allocate at least 100 MB for a short session.
Patience for privacy – Logcat can contain personal data (e.g., URLs, identifiers). Treat the file as sensitive.

Why filter by package?

Android’s logging system is global: every app and the system write to the same buffers. By default adb logcat shows everything, which quickly becomes unreadable. Filtering by the app’s package name (com.example.myapp) narrows the output to the messages you actually need, reducing file size and analysis time.

Step‑by‑step procedure

1. Verify ADB connection

Open a terminal (Command Prompt, PowerShell, or a shell).
Run adb devices. You should see a line like R58M7XXXX device.
If the list is empty, reconnect the cable, confirm the USB mode is set to File transfer, and accept the RSA fingerprint prompt on the phone.

2. Find the exact package name

If you already know the package, skip this sub‑step. Otherwise:

Install the app on the device (if not already installed).
Run adb shell pm list packages | grep -i myapp (replace myapp with a keyword). The output will contain the full package name.
Copy the exact string, e.g., com.example.myapp.

3. Choose a log buffer (optional)

Android maintains multiple buffers (main, system, crash, radio, events). Most app logs appear in main. If you suspect system‑level messages, you can combine buffers later with -b all. For now we stick with the default.

4. Start a filtered, continuous log capture

Run the following command, substituting your package name and a desired file path:

adb logcat --pid=$(adb shell pidof -s com.example.myapp) *:V > ~/myapp_log.txt

Explanation:

pidof -s returns the process ID of the app’s foreground process. Using --pid tells logcat to show only messages from that PID.
*:V sets the log level to VERBOSE for all tags, ensuring you capture everything.
> ~/myapp_log.txt redirects the output to a file in your home directory.

The command runs until you stop it (Ctrl + C). While it runs, interact with the app on the device to reproduce the issue you’re investigating.

5. Stop the capture safely

When you have reproduced the problem, return to the terminal and press Ctrl + C. ADB will terminate the logcat process, and the file will be closed. You now have a complete log of everything the app emitted during the test.

6. Verify the log file

Open the file with a text editor that can handle large files (e.g., VS Code, Notepad++, or less on Linux).
Search for keywords such as Exception, ANR, FATAL, or the specific tag you know the app uses.
If the file is empty, double‑check that the app was running while you captured the log and that the PID was correct.

Alternative filtering methods

If the app spawns multiple processes (common for services), the single‑PID filter may miss background logs. In that case use a tag‑based filter:

adb logcat -s MyAppTag:* > ~/myapp_tag_log.txt

Replace MyAppTag with the actual log tag used in the source code (often the class name). You can combine both filters:

adb logcat --pid=$(adb shell pidof -s com.example.myapp) -s MyAppTag:* > ~/myapp_combined.txt

Troubleshooting common issues

Device not listed in adb devices
- Ensure USB debugging is still enabled. Some manufacturers reset developer options after a reboot.
- Try a different USB port or cable. USB‑3 ports sometimes need a hub with power.
- On Windows, reinstall the adb driver via Device Manager (look for “Android Composite ADB Interface”).
Logcat shows no lines or only system messages
- Make sure the app is actually running. Use adb shell ps | grep com.example.myapp to confirm a PID exists.
- Some release builds strip log statements (e.g., they use Log.d only in debug builds). In that case you may need a debug build or enable adb logcat -v threadtime to see lower‑level messages.
File grows too fast, filling disk space
- Reduce verbosity: replace *:V with *:I (Info) or *:W (Warning).
- Capture for a limited time using timeout (Linux/macOS) – e.g., timeout 60 adb logcat ... > file.txt for a 60‑second window.
Log contains sensitive data you don’t want to keep
- Immediately redact or delete the file after analysis.
- Consider piping through grep -v "password" to strip known patterns.

Advanced tips for power users

Rotate logs automatically – Use logcat -f /sdcard/log.txt -r 1024 -n 5 on the device to keep five 1‑MB rotating files, then pull the latest with adb pull /sdcard/log.txt ..
Capture binary logs for later analysis – Add the -b all flag to include radio, events, and crash buffers, then open the file in Android Studio’s Logcat viewer for color‑coded tags.
Filter by time – Use -T "2024-01-01 12:00:00.000" to start logging from a specific timestamp, useful when you already have a long‑running log file.

Safety and privacy considerations

Logcat can expose:

Authentication tokens, API keys, or URLs that appear in debug statements.
Device identifiers such as IMEI or Android_ID if the app logs them.

Treat any captured file as confidential. Store it in an encrypted folder or delete it once you’ve extracted the needed information.

Wrapping up

By following the steps above you now have a reproducible workflow to capture a continuous, package‑specific logcat stream, store it safely, and troubleshoot the most common pitfalls. This method works on Android 6.0 (Marshmallow) and newer, regardless of the OEM, because it relies only on standard ADB commands.

Whenever you encounter a new crash or unexpected behavior, repeat the capture with the same settings. Over time you’ll build a library of logs that can be shared with developers or used to verify whether a bug is device‑specific.

User Comments (0)

Add Comment

No comments added yet.

Add Comment

Your Name: *

Comment Title: *

Your E-mail: * We'll never share your email with anyone else.

Your Comment: *

Comments will not be approved to be posted if they are SPAM, abusive, off-topic, use profanity, contain a personal attack, or promote hate of any kind.