Supported file types

Supported file types

logcat.ai accepts text-based system logs, a set of structured archives, and several binary capture formats it decodes for you: network captures, Bluetooth HCI snoops, SQLite snapshots, perfetto traces, automotive DLT traces, and gzip-compressed logs. Files are auto-classified at upload. Text logs are analyzed line by line; packet captures, traces, and databases are decoded and queried as structured data. You don’t need to label, decompress, or convert anything.

If you’ve tried to upload an image, a .dmg, or another binary and seen an error, this page explains why and what to send instead.

Accepted formats

Android bugreport archives

  • .zip Android bugreports. The standard adb bugreport output. Both flat zips (containing a bugreport-*.txt) and OEM-style nested zips (a bugreport zip wrapped inside another zip) are recognized.
  • Multi-zip uploads. You can upload more than one bugreport zip in a single batch. Each zip is validated independently; every archive in the batch must contain a valid Android bugreport.

Multi-file bundles

  • Log archives. A .zip, .7z, or tar archive (.tar, .tar.gz / .tgz, .tar.xz / .txz, .tar.zst / .tzst) that holds several logs is analyzed as a bundle: the platform unpacks the tree, classifies each file, analyzes them, and correlates across the set. Upload the archive as-is; there’s no need to extract it first. OEM megadumps and Qualcomm ramdumps are handled this way. The archive is recognized by its contents, so an unusual or missing extension still works.
  • Automotive board captures. A vendor dumpstate_board capture, an archive of the head unit’s DLT traces, QNX logs, network captures, and system traces (sometimes shipped with a .bin extension), is analyzed as a bundle. Each log inside gets its own analysis, and a screen capture recovered from the archive is shown on the dashboard.

Android text logs

  • logcat. Output from adb logcat, the Android Studio Logcat panel, and CI/CD log artifacts. Common buffer formats (main, system, radio, events, crash) and threadtime/brief/time formats are all detected.
  • JSON logcat exports. Android Studio’s structured JSON export.
  • ANR traces. traces.txt and per-incident ANR captures.
  • Tombstones. Native crash dumps from /data/tombstones/.
  • dumpsys output. Full or per-service dumps (e.g. dumpsys batterystats, dumpsys activity).
  • Event logs. logcat -b events output.

Linux text logs

  • dmesg. Kernel ring buffer output. All architectures supported: ARM, x86, MIPS, RISC-V.
  • Custom kernel logs. Vendor or board-specific kernel output, as long as it’s text.
  • syslog and journalctl exports. System daemon logs from any Linux distribution. journalctl --no-pager plain output works directly.
  • Application stdout/stderr. Text logs from services and daemons running on Linux devices.
  • QNX system logs. SLOG2 / slogger2 text output from a QNX real-time OS, common in automotive safety and instrument-cluster systems. Recognized as a structured log with its own severity levels.

Test artifacts

  • CTS / VTS / GTS / STS XML. Android Compatibility, Vendor, Google, and Security Test Suite result files.

Config files

  • Device and network configs. hostapd, OpenWrt UCI, firewall rules, and generic key-value config files are detected and analyzed alongside the logs they explain. A config uploaded with a capture from the same device gives the analysis the settings behind the behavior it sees.

CAN bus

  • candump traces. Text output from the open-source candump tool (Linux SocketCAN). This is the only CAN format auto-detected today. Captures from Vector CANalyzer, CANoe, or PEAK PCAN-View must be exported to candump-format text first; see Preparing automotive logs for the steps.
  • DBC files. These are uploaded separately through the References library in the console, not as a log. Once a DBC is registered, candump traces are decoded against it automatically.

Generic text logs

If you have a custom log format that isn’t listed above, upload it anyway. Unknown text formats are classified automatically and analyzed. This is how decoded vendor exports (telecom modem text, custom embedded logs) work.

Network and binary captures

These binary formats are decoded automatically at ingest. Upload them as-is, no conversion or decompression needed:

  • .pcap / .pcapng network captures. Decoded automatically and analyzed for network forensics: connection and protocol breakdowns, TLS/SSH fingerprints, and scan/beaconing/DGA threat signals, with a queryable dashboard. Deep Research and Quick Search can run SQL queries over the capture directly.
  • btsnoop Bluetooth HCI logs. Host-controller snoop captures, decoded automatically for analysis.
  • SQLite database snapshots. Decoded automatically. A snapshot can also act as a reference table that resolves opaque identifiers (device fingerprints, MAC addresses) in sibling logs from the same capture.
  • perfetto traces. Android/Linux system traces (.perfetto-trace, .pftrace, .perfetto). Search and Deep Research run SQL against the trace directly, and you get a dashboard.
  • DLT (Diagnostic Log and Trace). .dlt files and their .dlt.gz rotations, the AUTOSAR automotive logging standard. Decoded automatically into readable log lines that keep each message’s ECU, application, context, and level, so you can search and filter them by those fields like any other structured log.
  • gzip-compressed logs. A single-file .gz (e.g. logcat.gz, dmesg.gz) is transparently decompressed at upload; you don’t need to gunzip it first. (Multi-file archives like .zip and .tar.gz are handled as bundles, so you don’t need to extract them either.)
  • UTF-16 text logs. A log saved as UTF-16 (the usual result of redirecting adb logcat to a file on Windows) is transcoded automatically. No need to re-encode it first.

Kernel symbols (References)

A vmlinux is uploaded through the References library rather than as a log, and activates deep symbol-level analysis for every Qualcomm ramdump of that kernel build. Because a vmlinux is far larger than the per-file upload cap, it takes its own upload path. See Kernel ramdumps & References. A DBC file (CAN signal database, up to 10 MB) is registered the same way.

Not accepted

Binary files

The following are rejected when uploaded as a log. Common families:

  • Executables, libraries, and disk images: .exe, .dmg, .iso, .so, .dex, ELF, Mach-O. (A vmlinux is an ELF, but it isn’t a log: upload it to the References library instead, where it’s accepted.)
  • Raw memory images: a .bin on its own isn’t analyzable. The DDR and IMEM region blobs of a Qualcomm ramdump are .bin files, and they’re accepted inside the dump archive, where the manifests give them meaning. See Kernel ramdumps.
  • App-package archives: .jar and .apk. These are code packages, not logs. (Archives that hold logs, like .zip and .tar.gz, are accepted as multi-file bundles instead.)
  • Documents: PDF
  • Images: PNG, JPEG, RIFF

Vendor binary log formats

Proprietary diagnostic captures are rejected in their native binary form. Convert them to a text export first using the vendor tool. These pages show how:

Why a file gets rejected as binary

Apart from the binary formats it explicitly decodes (see Network and binary captures above), a file is treated as a log only if it’s predominantly printable text. A file that isn’t a recognized binary capture and carries a high share of non-printable content is treated as binary and rejected. If a text log is wrongly rejected, export a clean text version and re-upload.

Prepare before upload

Pick the guide for your system:

Size limits

Two separate limits apply:

  • Per file: 250 MB by default, the same for every account. This covers the vast majority of bugreports, bundles, and long-running captures. Kernel symbol files (vmlinux) are exempt: they go through the References library, which takes large uploads.
  • Total storage: how much uploaded data you can hold at once is set per account. Your billing page shows your allowance and what you’ve used. See Plans & pricing.

Multi-file uploads

You can upload several files in a single batch. Each file is classified and validated on its own:

  • Multi-zip bugreport batches: every archive must independently contain a valid Android bugreport.
  • Mixed-format batches: for cross-file investigations (e.g. a bugreport plus a kernel dmesg from the same device), see Delta Comparison.