Life of a bug

The Android Open Source Project maintains a public issue tracker where you can report bugs and request features for the core Android software stack. (For details on this issue tracker, see Reporting bugs). Reporting bugs is great (thank you!), but what happens to a bug report after you file it? This page describes the life of a bug.

This isn't a customer support forum. For support information, see the Pixel help center. Support for other devices is provided by the device manufacturers or by the carriers selling those devices.

Support for Google apps is through Google's support site. Support for third-party apps is with each app's developer, for example, through the contact information provided on Google Play.

Here are the key stages in the life of a bug:

  1. A bug is filed, and has the state New.
  2. An AOSP maintainer periodically reviews and triages bugs. Bugs are triaged into one of four buckets: New, Open, No-Action, or Resolved.
  3. Each bucket includes a number of states that provide more detail on the fate of the issue.
  4. Bugs marked Resolved will be included in a future release of the Android software.

Bucket details

We use the Status field in Issue Tracker to specify the status of an issue in the resolution process. This is consistent with the definitions specified in the Issue Tracker documentation.

New issues

New issues include bug reports that haven't been acted upon. The two states are:

  • New: The bug report hasn't been triaged (that is, reviewed by an AOSP maintainer).
  • New + Hotlist:NeedsInfo: The bug report has insufficient information to act upon. The person who reported the bug needs to provide additional details before it can be triaged. If enough time passes and no new information is provided, the bug may be closed by default, as one of the No-Action states.

Open issues

This bucket contains bugs that need action, but that are still unresolved, pending a change to the source code.

  • Assigned: The bug report has been recognized as an adequately detailed report of a legitimate issue and the bug has been assigned to a specific contributor to assess and analyze.
  • Accepted: The assignee has acknowledged the issue and has started to work on it.

Typically, a bug starts in Assigned, and remains there until someone intends to resolve it, at which point it enters Accepted. However, note that this isn't a guarantee, and bugs can go directly from Assigned to one of the Resolved states.

In general, if a bug is in one of the Open states, the AOSP team has recognized it as a legitimate issue, and a high-quality contribution fixing that bug is likely to get accepted. However, it's impossible to guarantee the completion of a fix in time for any particular release.

No-Action issues

This bucket contains bugs that are deemed to not require any action.

  • Won't Fix (Not reproducible): An AOSP contributor attempted to reproduce the behavior described, and was unable to do so. This sometimes means that the bug is legitimate but simply rare or difficult to reproduce, or there wasn't enough information to fix the issue.
  • Won't Fix (Intended behavior): An AOSP maintainer has determined that the behavior described isn't a bug, but is the intended behavior. This state is also commonly referred to as working as intended (WAI). For feature requests, an AOSP maintainer has determined that the request isn't going to be implemented in Android.
  • Won't Fix (Obsolete): The issue is no longer relevant due to changes in the product.
  • Won't Fix (Infeasible): The changes that are needed to address the issue aren't reasonably possible. This status is also used for issues reported that can't be handled in AOSP, typically because it's related to a customized device or to an external app, or the reporter mistook this tracker as a help forum.
  • Duplicate: There was already an identical report in the issue tracker. Any actual action will be reported on that report.

Resolved issues

This bucket contains bugs that have had action taken, and are now considered resolved.

  • Fixed (verified): This bug has been fixed, and is included in a formal release. When this state is set, we try to also set a property indicating which release it was fixed in.
  • Fixed: This bug has been fixed (or feature implemented) in a source tree, but might not yet been included in a formal release.

Other stuff

The states and lifecycle above are how we generally try to track software. However, Android contains a lot of software and gets a correspondingly large number of bugs. As a result, sometimes bugs don't make it through all the states in a formal progression. We try to keep the system up to date, but we tend to do so in periodic bug sweeps where we review the database and make updates.