How to Capture Continuous Android System Logs to a File Using ADB and Logcat (No Root)

Why you need a persistent log file

When an app crashes, a feature misbehaves, or a battery‑draining service appears, the Android logcat buffer contains the low‑level details you need to diagnose the problem. By default the buffer lives only in RAM and disappears after a reboot. Saving it to a file gives you a permanent record that you can share with developers, archive for later analysis, or use to spot patterns.

Before you start

• Computer with ADB installed – Windows, macOS, or Linux.
• USB cable – use the one that came with your phone to avoid connection glitches.
• Charging – keep the device plugged in; continuous logging can drain the battery quickly.
• Enough storage – a few hundred megabytes per hour of verbose logging is typical.
• Developer options enabled – see the first step below.

Step 1 – Install the Android Debug Bridge (ADB)

Step 2 – Enable USB debugging on the device

Step 3 – Verify the connection

Step 4 – Choose a log‑storage location on your PC

It is safest to keep the log file outside any synced cloud folder (e.g., Dropbox) because logcat may contain personal identifiers (IMEI, device IDs, usernames). Create a dedicated folder, for example:

mkdir -p ~/android-logs

We will write the file system.log into this directory.

Step 5 – Start a continuous log capture

cd ~/android-logs

adb logcat -v time -b all -G 10M | rotatelogs -L system.log -l 10M -n 3

If rotatelogs is not available (common on Windows), use the built‑in logcat option -r for size‑based rotation:

adb logcat -v time -b all -r 10240 -n 3 -f system.log

Explanation of the flags:

• -v time – prepend each line with a timestamp, making later analysis easier.
• -b all – capture every buffer (main, system, radio, events, crash) for a complete picture.
• -r 10240 – rotate the file after 10 240 KB (≈10 MB).
• -n 3 – keep three rotated files (system.log, system.log.1, system.log.2).
• -f – direct output to the specified file instead of stdout.

Step 6 – Optional: filter the output

Full‑buffer logging can be noisy. If you are interested in a particular app or tag, add a filter expression after the command. Example – capture only logs from the package com.example.myapp and errors from the system:

adb logcat -v time -b all -r 10240 -n 3 -f system.log \
  *:W com.example.myapp:D

Here *:W sets the default priority to Warning, while com.example.myapp:D keeps Debug level messages for the chosen app.

Step 7 – Verify that logging is working

head -n 20 system.log

You should see timestamped lines that mention your app’s package name or the system component you interacted with. If the file is empty, double‑check that USB debugging is still enabled and that the device is listed by adb devices.

Step 8 – Automate the capture (optional)

For developers who need logs every time the device boots, you can create a simple batch (Windows) or shell (macOS/Linux) script and add it to the computer’s startup routine.

Windows batch example (save as start-log.bat)

@echo off
set LOGDIR=%USERPROFILE%\android-logs
if not exist "%LOGDIR%" mkdir "%LOGDIR%"
adb logcat -v time -b all -r 10240 -n 3 -f "%LOGDIR%\system.log" *:W

Linux/macOS shell example (save as start-log.sh)

#!/bin/bash
LOGDIR="$HOME/android-logs"
mkdir -p "$LOGDIR"
adb logcat -v time -b all -r 10240 -n 3 -f "$LOGDIR/system.log" *:W

Make the script executable (chmod +x start-log.sh) and add it to your login items.

Step 9 – Retrieve the log for analysis

When you have captured enough data, pull the files to a convenient location:

adb pull ~/android-logs/system.log ~/Desktop/
adb pull ~/android-logs/system.log.1 ~/Desktop/
adb pull ~/android-logs/system.log.2 ~/Desktop/

On Windows replace the paths with the appropriate drive letters. Once on your PC you can open the logs with any text editor, import them into tools like Android Log Viewer, or feed them to grep for keyword searches.

Troubleshooting common issues

• Device not listed by adb devices
  • Make sure the USB cable is data‑capable (charging‑only cables won’t work).
  • Restart the ADB server: adb kill-server && adb start-server.
  • On some OEM skins you need to change the USB mode to “File Transfer (MTP)”.
• Log file stays empty
  • Confirm that USB debugging is still enabled; some devices disable it after a reboot.
  • Check that you used the -b all flag; without it you only get the “main” buffer which might be empty if the issue is in the radio or system layer.
• Logcat stops after a few minutes
  • Older Android versions limit the buffer size; use adb logcat -G 16M to increase it before starting capture.
  • Ensure your PC has enough free RAM – the command streams data, but a full buffer can cause drops if the write speed is too slow.
• Privacy concerns – logs contain personal data
  • Before sharing a log, scrub it. Simple grep -v "IMEI" system.log > cleaned.log removes lines containing the keyword.
  • Consider using the -p flag to limit the output to specific tags only.

Best‑practice checklist

• Keep the log rotation size low (5‑10 MB) to avoid filling the disk.
• Stop logging when you have reproduced the issue – long logs are harder to parse.
• Use clear filter expressions to reduce noise.
• Never ship raw logs to untrusted parties; they can reveal passwords, tokens, or device identifiers.
• After you finish, you can clear the device buffers with adb logcat -c to free RAM.

What to do with the captured log

Once you have a log file, you can:

1. Search for Exception or FATAL EXCEPTION to locate crashes.
2. Identify repeated W/ (warning) lines that precede a slowdown.
3. Provide the filtered snippet to a developer when filing a bug report.

Remember that the most useful logs are those captured exactly at the moment the problem occurs – start the capture before you trigger the issue.