DEV Community

Damian Witkowski
Damian Witkowski

Posted on

Conflicting Android beta reports: separating observations from verified bugs

Two reports from a small Android beta described different behaviour for the same breathing timer: one tester said it restarted after switching apps, while another said it resumed correctly. The second report identified a Pixel 7 running an Android 15 beta. The device and Android version for the first report were still unknown when these notes were prepared.

A separate report described a home-screen widget whose money-saved value matched the app only after a manual refresh.

These are user-reported observations. They do not establish the cause, prove a general Android problem, or demonstrate that a fix works.

The follow-up test plan

For the timer, record the device model, Android version, exact steps, time spent outside the app, and the displayed state before and after returning. Repeat the same sequence on the same device before comparing it with another device.

For the widget, use fictional input values. Record the app value and widget value, then check them after reopening the app and after a manual widget refresh. Keep those actions separate so the report identifies which action changed the result.

For each issue, keep a distinction between:

  • Reported: a tester described it.
  • Reproduced: the same steps produced it during an observed check.
  • Changed: an implementation change was made.
  • Verified: the original steps were repeated on the new build and the expected result was observed.

At this stage, these notes cover the reports and proposed follow-up checks. They do not claim an implementation change or a verified fix.

Use sample data in screenshots and reports. Device model, OS version and reproduction steps are useful; private journal text, account details and health information are unnecessary for these checks.

Top comments (0)