How to Write an Android Bug Report

Start with a reproducible environment

Record the app version and build, Android version, device or emulator model, and relevant settings. Note account state and test data without including passwords or personal information. A report about an old build should say so.

• Identify the exact build you tested.
• Record the screen, account state and network conditions needed to start.
• Describe any settings that affect the issue, such as large text or a different language.

Write one action per step

Begin from a state another tester can reach. Use a short numbered sequence with visible controls and concrete input. Keep unrelated issues in separate reports.

• Open the app and navigate to the affected screen.
• Enter the test value or perform the action that triggers the issue.
• Describe the visible outcome and how often you observed it.

Separate the expected and actual result

The expected result explains what should happen and why that is reasonable. The actual result records what you saw. Avoid assuming a root cause unless it has been verified. Severity describes impact; the team still decides fix priority.

Worked example: a hidden form action

Illustrative scenario, not a measured customer result: after increasing text size, a form action falls below a fixed panel and cannot be reached. A useful report identifies the build, window size, text setting, navigation steps and the expected scrolling behavior. Attach a redacted screenshot reference if you have one.

Make evidence useful and safe to share

A screenshot or short recording should show the relevant state. Reference a file or an access-controlled attachment in your issue tracker. Remove credentials and personal data from captures and logs before sharing. This website does not upload evidence.

Close the loop with a retest

After a fix, rerun the original steps on the new build and record passed, failed or could not verify. Include adjacent flows in regression checks. Do not mark an issue fixed simply because a change was made.

Is this the same as an Android system bugreport?

No. This is a structured issue description for a person or issue tracker. Android system bugreports contain diagnostic logs and are collected separately with Android tools.

Does the generator test my app?

No. You enter observations from your own testing. The generator formats them; it does not inspect an APK, collect device logs or verify a defect.

How much detail is enough?

Include enough context for another person to reach the same state, follow the steps and compare outcomes. Keep the report focused on one issue.