How to collect Android bug report logs for QA

To collect Android bug report logs during QA, use Logcat for messages around a failing action, or capture a full Android bug report when the developer needs broader device diagnostics. Record the failure time and app build beside the file. A log without the test steps can leave the developer guessing which event matters.

This guide is for testers and developers working on an authorised test device. For the rest of the issue, use the good bug report guide.

Which Android logs should you collect?

Agree on the evidence with the person investigating. A clipped button may need a screenshot and text-size settings; collecting a system archive for every visual issue adds work to the handoff.

Evidence	What it contains	When to consider it
Logcat capture	Android and application log messages	You can repeat a failure while collecting logs
Full Android bug report	Logs plus system diagnostic output	Engineering needs to investigate beyond the app's messages
App logs sent through a reporting SDK	Messages the app developer chose to record	Your test build already includes reporting and useful logging

Android's Logcat reference describes its log buffers; the bug report guide explains the larger diagnostic archive.

What should you record before collecting logs?

Write down the app version and build, device model, Android version and test environment. Note anything that could change the result: an upgrade from an older build, a denied permission or an upload left pending while the phone was offline.

Use a test account and test data where possible. Decide where the capture will be stored and who needs access before you collect it. If this is a failure you've only seen once, save the available evidence before trying fixes that change the device's state.

For a USB capture, install Android SDK Platform-Tools, enable USB debugging in Developer options and accept the debugging prompt for your trusted computer. Check the connection:

adb devices

The device should appear with status device. If it shows unauthorized, unlock the phone and check the prompt. Google's ADB connection guide covers the setup. Replace SERIAL in the commands below with the identifier shown for your test device; selecting it explicitly avoids collecting from a different connected phone.

How do you capture Logcat during a failing test?

Start a capture before repeating the steps:

adb -s SERIAL logcat -v threadtime > qa-logcat.txt

Reproduce the problem, note the failure time and time zone, then press Ctrl+C to stop. Open the file and check that it contains messages around that time. Use a new filename for each run.

The threadtime format includes timestamps, process and thread IDs. If the failure has already happened, -d dumps the logs still in the buffers and exits:

adb -s SERIAL logcat -d -v threadtime > qa-logcat-after-failure.txt

Android stores logs in circular buffers, so this cannot recover messages that have already been overwritten. Available options vary by OS; check them with adb -s SERIAL logcat --help. These behaviours are documented in the Logcat command-line reference.

Avoid clearing the buffer while you're trying to preserve an intermittent failure. If the output is noisy, ask engineering which package, tag or time window they need. Filtering only for errors may hide the earlier action that explains the failure.

Can you use Android Studio instead?

Open View → Tool Windows → Logcat, select the test device and use the package filter to focus the view. Android Studio's Logcat guide documents the controls and query syntax. Keep the timestamps when you copy a relevant excerpt, and tell the developer which filter you used.

How do you capture a full Android bug report?

After reproducing the issue, run this from the folder where you want the report saved:

adb -s SERIAL bugreport

Wait for collection to finish. The ZIP contains a main report text file with system diagnostics and logs. The build ID in its generated filename identifies the Android system build; record your app's build separately.

Without a computer, enable Developer options, select Take bug report, follow the prompts and open the notification when collection finishes. Device menus can differ. Google's capture instructions cover both routes.

Check the archive before sharing it. Use your team's restricted diagnostic-file location, then link it from the issue. A public ticket is a poor place for a device-wide capture.

What should accompany the log file in the ticket?

Give engineering a way to connect the file to one attempt. Copy this alongside the reproduction steps:

App version and build:
Device model / Android version:
Test environment:
Setup: [account state, permissions, fresh install or upgrade]

Steps:
Expected result:
Actual result:
Failure time and time zone:
Reproduction frequency: [failed attempts / total attempts]

Capture filename or restricted link:
Capture started / stopped:
Any filter used:
Relevant timestamp or excerpt:
Changes made after the failure: [restart, reinstall, cleared data, none]
Screenshot or recording:

For example, a fictional upload issue might say: “On build 148, reconnecting Wi-Fi leaves the queued photo spinning. Failed at 10:42:16 UTC, two of three attempts. Capture started before disconnecting; app was left open after the failure.” The developer can look at that attempt first, then compare it with a successful retry.

Describe what you observed without guessing the cause. An error near the failure is worth pointing out, but it doesn't by itself prove why the upload stalled.

What should you check before sharing Android logs?

Review the capture for credentials, account details, message contents and other private data. Check the archive's other files too. If you need to remove sensitive material, share a reviewed copy and say what you removed; keep any original only in the location your team permits.

Avoid uploading the file to an unfamiliar online analyser just to find a timestamp. Start with your local tools and the investigating developer. They can ask for more evidence if the first capture doesn't answer the question.

Where does BugScreen fit into this workflow?

For routine QA reports, BugScreen's embedded Android SDK can attach the application messages your developer sends through its logging API. Its in-memory buffer is about 1 MB and drops the oldest entries when full; it does not survive an app restart. The Android logging guide shows how to feed it useful messages.

The SDK does not automatically intercept Logcat or collect network errors and stack traces. The separate companion app cannot read another app's logs. Keep a requested system ZIP in your team's diagnostic-file workflow, with a link from the issue.

If your testers repeatedly have to assemble screenshots and application context by hand, try BugScreen with a test build.