“The help screen looks wrong” is a useful starting point for a conversation. It is not yet enough information for another developer to investigate.

Which build? What device? What steps? Does “wrong” mean stretched, cropped, blurry, or different from the instructions?

A useful bug report reduces those unknowns. It preserves the evidence, separates observations from explanations, and gives someone else a specific sequence to try.

Imagine an Android app with an embedded web-based help screen. A tester reports that an illustration looks stretched. The available evidence includes a screenshot, a small configuration response, a PDF guide, and the app package.

Here is a workflow for organizing that evidence using six focused tool sites. Use the parts relevant to your report; a simple issue may need only a screenshot and clear steps.

1. Turn the complaint into steps without rewriting the evidence

Start by separating the reporter’s explanation from the raw evidence.

For our example, the explanation might become:

1. Open the app in portrait orientation.

2. Navigate to Help, then Getting Started.

3. Wait for the illustration to load.

4. Compare the illustration with its source image.

Keep expected and observed behavior in separate fields. “The illustration should preserve its proportions” is a requirement to confirm. “The circle in the illustration appears taller than it is wide” is an observation a reviewer can investigate.

TextToolsBase includes text cleanup, counting, and comparison utilities that can help organize the explanatory text. Compare the edited report with the original so that shortening it does not remove an important condition.

Keep logs and stack traces separate. Their timestamps, line breaks, capitalization, and repeated entries may matter. Cleaning prose and altering diagnostic evidence are different operations.

2. Identify the build before comparing results

Two people can follow identical steps and get different results because they are running different builds.

Record the package name, version name, version code, installation source, device model, and Android version. For a web-based screen, record the relevant WebView version when it can be obtained. Note display settings if the problem changes with text size, orientation, or zoom.

APKLint provides APK and AAB inspection tools that can help examine package information, manifests, and permissions. Use the artifact associated with the report, rather than assuming a similarly named package is the same build.

APK analysis includes server-side processing, so review the tool’s handling notes before uploading a private build. Static inspection establishes useful context; it does not reproduce the visual defect or explain runtime behavior by itself.

If certificate information is relevant, remember that reading signing metadata is not the same as cryptographically verifying a signature.

3. Make configuration readable while preserving the original

Suppose the help screen uses a small configuration response like this fictional example:

{"screen":"getting-started","asset":"guide-v2.png","imageMode":"stretch"}

Formatting it makes the individual fields easier to inspect:

{
  "screen": "getting-started",
  "asset": "guide-v2.png",
  "imageMode": "stretch"
}

WebDevToolsBase includes a JSON formatter for this kind of inspection. Keep the original response and work on a copy.

The field names above are invented for this example, not Android settings. A value called imageMode is only meaningful if the application reads it. Trace that value through the actual code before treating it as an explanation.

Also record when and where the response was captured. A response from a different environment or after a configuration update may not describe what the reporter saw.

4. Preserve the screenshot before making it easier to read

A cropped attachment can help a reviewer find the relevant detail. It can also remove the information needed to understand the issue.

Keep the original screenshot at its original dimensions. If you create a close-up, label it as a crop and attach it alongside the original. Retain enough surrounding interface to show where the problem occurs.

ImgToolsBase offers cropping, resizing, conversion, and compression tools for preparing a separate viewing copy. For a layout or sharpness bug, avoid resizing or compressing the only copy of the evidence: those operations can change the appearance being investigated.

In the report, distinguish the source illustration from the screenshot of that illustration inside the app. They answer different questions. One shows the asset; the other shows how the application rendered it.

5. Replace “stretched” with a measurable comparison

Assume the source illustration measures 1920 × 1080 pixels. If the requirement is to display the complete image at a width of 960 while preserving its aspect ratio, the corresponding height is:

Expected image height = 1080 × (960 / 1920)
                      = 540

CalcToolsBase provides calculators for checking numerical relationships such as ratios and proportions. Write down the inputs and formula so another person can verify the result without relying on a screenshot of a calculator.

A 960 × 600 container does not automatically establish a bug. The image might retain its proportions with padding, or it might be cropped intentionally. Measure the rendered image and identify the intended fitting behavior.

For a web-based screen, CSS distinguishes these cases: contain preserves proportions while fitting the image inside its box; cover preserves proportions while allowing cropping; fill can stretch it when the proportions differ. MDN’s object-fit reference explains the behavior.

Use the same coordinate system for both displayed dimensions. Do not mix CSS pixels with device pixels in the same comparison.

6. Attach the relevant instructions with their context

Sometimes the disagreement is between the application and its documentation. In that case, the report needs the relevant instruction as well as the screenshot.

PDFToolsBase includes splitting, extraction, and organization tools for preparing relevant pages from a longer guide. Keep the original document and note its title, version, and original page numbers when attaching an excerpt.

Include nearby conditions that affect the instruction. A sentence about tablet layout should not be presented as a requirement for every phone screen.

Preserve the document features needed for the investigation. The site’s current general PDF compressor rasterizes pages, removing selectable and searchable text. That is a poor fit when the reviewer needs to copy a command or search an error message.

Finally, check whether the guide applies to the reported build. An outdated guide is evidence of a documentation mismatch, not proof that the current interface is defective.

A report template another developer can work from

Bring the evidence together in a short, structured report. Fill in observed results; do not guess missing values.

Title:
  [Specific visible behavior and affected screen]

Build and environment:
  Package:
  Version name and version code:
  Build or artifact identifier:
  Installation source:
  Device and Android version:
  WebView version, if relevant:
  Orientation and relevant display settings:

Preconditions:
  [Account state, configuration, network state, required data]

Steps to reproduce:
  1.
  2.
  3.

Expected behavior:
  [Behavior and the requirement supporting it]

Observed behavior:
  [What actually happened]

Frequency:
  [Observed failures / attempts, or “not yet measured”]

Evidence:
  Original screenshot:
  Labeled close-up, if useful:
  Original configuration or logs:
  Source image dimensions, if relevant:
  Guide version and page references:

Working hypothesis:
  [Possible explanation, clearly labeled as unconfirmed]

Open questions:
  [Information still needed]

The tools help prepare individual pieces of evidence. The report must connect them: which build produced the screenshot, which configuration it used, and which requirement defines the expected result.

A report assembled this way gives another developer enough information to attempt reproduction. The next step is to run that attempt, record the result, and revise the explanation as the evidence develops.